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

List:       kfm-devel
Subject:    Re: Proposed incompatible change: IO-slaves
From:       Waldo Bastian <bastian () kde ! org>
Date:       2000-05-30 22:47:49
[Download RAW message or body]

On Tue, 30 May 2000, David Faure wrote:
> On Mon, May 29, 2000 at 03:28:12PM -0400, Dawit Alemayehu wrote:
> > On Mon, 29 May 2000, Waldo Bastian wrote:
> > > Hiya,
> > >
> > > I would like to change the io-slave interface to use KURL instead of
> > > path & query pairs. This change allows us to solve problems with
> > > non-ascii paths with unknown encodings. Since we don't know the
> > > encoding of these paths it is impossible to convert them to unicode
> > > reliable, so we can't pass them in a QString. This problem is solvable
> > > within the KURL class, but for that we must make sure to pass the URL
> > > around.
> > >
> > > This change involves changing _ALL_ io-slaves so I hope that no one is
> > > currently working on big changes in his/her io-slave. If you do, please
> > > let me know ASAP.
> > >
> > > Make sure to yell if you have objections to this change. Otherwise I
> > > will commit my changes wednesday.
> >
> > Hmmm... I thought the use of KURL in the io-slaves was avoided because it
> > slowed them down considerably ?
>
> More or less. More exactly, a duplication problem.
> The reason was: what's the point in resending
> - the protocol
> - the host
> - the port
> - the user
> - the password
> to a slave which we know is already connected to all of those ?

The alterative is to send a path, query and 8-bit-path seperate. 

> If you pass the full URL, then we have to _assume_ it matches
> all of the above, which were given to the slave in setHost.
> Since that's the intended way (AFAIK), it means we are _willingly_
> passing redundant information. I'm fine with this, but I want to point
> this out so that the code in the ioslave doesn't start to check for
> all of those at the beginning of all commands (as it was done previously).

Well.. the io-slave interface was obviously not designed with http in mind 
and seems to be very oriented towards the file protocol. If you look at the 
slaves you will see that  the first thing a lot of them do is to reconstruct 
the full URL.

None of the slaves actually do anything usefull in the setHost() call btw.

> And yes, passing a KURL over the pipe is 8 times more than passing a
> string, unless it's passed _as_ a string, but then it needs reparsing
> on the slave's end...

Up to now we had no reason to believe the speed of the pipe was a bottleneck. 
Sending 20 bytes more shouldn't be noticable.

Cheers,
Waldo

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