Slows starting of downloading with KIO

Thiago Macieira thiago at kde.org
Tue Dec 20 11:52:09 GMT 2005


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?

Take, for example, ncftp: it does that. If you try to tab-complete, it'll 
list the dir and get the completions. If you ls/dir, it'll cache the 
hierarchy for further completions.

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?
-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

5. Swa he géanhwearf tó timbran, and hwonne he cóm, lá! Unix cwæð "Hello, 
World". Ǽfre ǽghwilc wæs glæd and seo woruld wæs fréo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051220/19763794/attachment.sig>


More information about the kde-core-devel mailing list