Slows starting of downloading with KIO

[David Faure]

On Tuesday 20 December 2005 12:52, Thiago Macieira wrote:
> David Faure wrote:
> >Ah! That is true, and that's a direction I like, much more than
> > complexifying the CopyJob algorithm even more to cheat on the progress
> > info somehow.
> >
> >The problem is that the KIO job methods (e.g. KIO::copy()) take a KURL
> >or a KURL::List, which loses the information that we might already have
> > about those urls. The solution would be to add methods that take
> > KFileItems, and that extract from those fileitems the data that CopyJob
> > would get in the stat'ing phase anyway, in order to skip that phase.
> 
> How about if the ioslave cached this information?

It's an idea, but you'd lose the cached info when the ioslave is killed due to
being idle, or when the app uses more than one ioslave.

This is exactly why we implemented the cache in the client side: KDirListerCache.
It's just that KIO jobs don't use it. Oh... that's another way of doing it: instead of
changing the KIO job API, we could let the jobs lookup inside the KDirListerCache
(which is a singleton) in order to extract the info about those URs, if it's there.
No impact on the API and on konq, so this sounds like a nice solution to me :)

> The only problems here are:
> 1) cache-invalidation a.k.a. refreshing
> 2) duplication of information in Konqueror and in the ioslave
>
> Does Konqueror set the cache meta-data when Reload is pressed in the list 
> and icon view modes?

That would be KDirLister::openURL, and no it doesn't set metadata, since
initially the reload metadata was mostly for KIO::get (which sets "reload"
when the bool is true).

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).