Slows starting of downloading with KIO

[David Faure]

On Monday 19 December 2005 22:52, Andras Mantia wrote:
> On Monday 19 December 2005 23:13, Martijn Klingens wrote:
> > In Andras' particular case he's already looking at the file listing
> > from kio-ftp. Since a directory listing in FTP is roughly similar to
> > ls -l output we can already safely *KNOW* whether the targets of the
> > links are files or folders and skip the statting altogether for the
> > files.
> 
> Exactly. I'm sure in many case the information is already available, it 
> is just not reused correctly.

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.

> But the same problem happens in the case David described. Get my 
> example, but go one level up and download the whole directory. The 
> stating still happens.
No, the recursive listing; which is needed anyway.

> Stupid question: does a recursive listing require stating in KIO?
Yes and no (the question doesn't make sense from a KIO point of view :)
Listing calls listDir(), stating calls stat(), so technically listing is not stating.
However in practice for FTP, stating means listing and extracting one line from it,
so both operations are similar, except listing is done in one go, and stating is
done for every url so it's slower.

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