[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    konq history manager (Re: ktempfile)
From:       David Faure <faure () kde ! org>
Date:       2007-11-09 11:09:01
Message-ID: 200711091209.02632.faure () kde ! org
[Download RAW message or body]

On Thursday 08 November 2007, Kåre Särs wrote:
> On Thursday 08 November 2007, David Faure wrote:
> > I think that what people missed in this thread is that history is shared
> > among konqueror windows, which could be in different processes. So we do
> > need to write to the file immediately so that your url comboboxes all have
> > the new url in it (this isn't about statistics, it's about the url combo's
> > items). Well, more precisely: the new url is sent to other windows using
> > dcop/dbus, but if you open a new window (in a new process) it will read
> > from the kconfig file. So a 5 minutes autosave would just lead to bugs.
> >
> 
> Using the hard drive for Inter Process Communication is not very efficient :( 
Right, we're not. IPC is between running processes and that is done with DBUS.
The hard drive is used for persistence. What if you open konq, browse, close, and then open a new one...

> Couldn't the new process ask the old ones for the current url history and 
> then if that fails read from the disk?
Shipping large amounts of data via IPC is inefficient too. The current DBUS interface
is for shipping "entry added" and "entry removed" stuff, which is fine. But sending 500
history items via DBUS would be very inefficient AFAIK (waking up two processes
one after the other), while reading from disk could just come from a cache...
Feel free to profile it and tell me I'm wrong though :)

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]