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

List:       kde-core-devel
Subject:    KIO design questions
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-10-28 21:02:18
[Download RAW message or body]

I am not completely sure if this is for core-devel or kfm-devel. I opted for 
core-devel, since most people reading kfm-devel read core-devel as well and 
not necessarily the other way round. Hope this was the right decision :-)

Something that's bothering me for a while now: If you open a file over kio, 
there are multiple connections opened for the same file. First KIO tries to 
determine the mime type. At least for kio_http this is by issuing a HEAD 
command. I am not sure what other protocols do, but I have the slight 
impression that those also open a connection for determining a mime type and 
close the connection afterwards.

When the app (or kfmclient for legacy apps) then actually downloads the file 
the whole process of setting up the connection starts again. This is not an 
issue at all on a fast LAN. _HOWEVER_, over slow links this seriously wastes 
a lot of time and bandwidth. I have seen it happen that only after a couple 
of retries ('F5') the mime type is finally known, after which the darn thing 
tries to reconnect again instead of reusing the already open connection.

Why is this? Can't IO slaves be transferred to the new app as soon as it is 
started? KIO can keep the connection open while the app is starting and even 
start downloading at a small pace so the app essentially starts with a 
prebuffered file. Of course this download should not saturate bandwidth and 
should be merely used as an advanced form of keep-alive. If a user cancels 
the download (e.g. if there is no app associated with the mime type) then KIO 
should close the connection, IMO, not earlier.

Any ideas why the design is like this and whether this can be fixed somehow 
without a major KIO overhaul?

Martijn

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