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

List:       kfm-devel
Subject:    Re: Was Re: Bug#1483: 1483 Ever climbing number of kioslaves.
From:       Waldo Bastian <bastian () suse ! com>
Date:       2000-04-19 5:58:27
[Download RAW message or body]

On Tue, 18 Apr 2000, you wrote:
> > We basically do a HEAD to catch the mimetype. We need the mimetype to
> > know which KPart is going to handle the document. This KPart will then
> > request the actual document.
>
> Ahh, so there is a reason -- the architecture.  Curious, can the kio
> slave architecture be modified a bit to either:
>
> 	(1) hand the entire document back to konqueror/other requestor and then
> have konqueror/other pass the data to the proper KPart; or
> 	(2) after retrieving the document, assign the document an ID (such as a
> temporary file name) which it passes to Konqueror/other requestor, then
> Konqueror/other can give the ID to the KPart, which then gets the data
> (either from the file system or from the slave).

We could try do to a GET, put the job/slave on hold as soon as we have the 
mimetype and then transfer the job/slave to the part which handles it. If the 
part which handles the request happens to be a process we need to abort the 
GET and then the part can restart the transfer itself. 

> It seems to me that the amount of time/bandwidth used for all these HEAD
> requests (and associated DNS lookups if the connection cannot be held
> open) will have a significant affect on performance.

I believe the HEAD request was designed to do cache validation so it can't be 
too bad. We could reduce DNS lookups a bit by caching the last used host.

Cheers,
Waldo

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