[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 () kde ! org>
Date:       2000-04-19 18:25:53
[Download RAW message or body]

On Tue, 18 Apr 2000, Dawit A wrote:
> On Wed, 19 Apr 2000, Waldo Bastian wrote:
> > 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.
>
> Waldo, please bear with me here because I am still confused.  While you
> were on away I had to patch kio_http to stop it from sending mime-type when
> the response from the header contained a redirection and the redirection
> header incorrectly contained a Content-Type entry (obviously a buggy server
> implementation).  My question here is that when a get action is requested,
> isn't the parsing of the header information completed before the data is
> sent/transfered to the calling application ( the part ) ?? 

It's sent to the calling application (Konqueror), but that doesn't have to be 
the part which will finally handle the request.

> Perhaps I am
> missing something here ??  May be there is no garauntee that the mime-type
> information from ::readHeader() reaches the application before the data
> does ??

No that is guaranteed.

> > > 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.
>
> Ahh... that would definitely make sense.  

Added that to KSock.

> If this is the case then we should have no problem either :
>
> 1.) doing the HEAD request, only when we want to validate the cache based
> on the user choice we discussed on the other mail.  I mean if the cache is
> turned off this would not be required, right ??  OR

> 2.) timeout quickly if no response to the HEAD and attempt the actual
> request. Which as you stated might fail under 99% of the conditions anyway.

What's the gain of that?

Cheers,
Waldo

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