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

List:       kde-devel
Subject:    Re: IO-slave configuration
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2001-05-18 6:00:59
[Download RAW message or body]

On Thursday 17 May 2001 14:34, Waldo Bastian wrote:
> On Thursday 17 May 2001 02:46, Sergio Moretti wrote:
> > On Wednesday 16 May 2001 20:24, Waldo Bastian wrote:
> > > On Wednesday 16 May 2001 04:18, Sergio Moretti wrote:
> > > > Hi,
> > > > I hope to not come too late to put my review ;) on the new slave
> > > > configuration framework.
> > > > Here some points:
> > > > Lack of a per-slave configuration, I mean the possibilty to have a
> > > > different configuration for every currently active slave's
> > > > instance.
> > >
> > > You mean with slaves in connection-oriented mode? You can call
> > > slave->setConfig() for those... does the slaveConfig stuf interfere
> > > badly with that?
> >
> > no, I was thinking about an application running 2 or more ftp slaves in
> > the same time, how can I configure each one indipendently from the
> > others?
>
> By running them in connection oriented mode. Otherwise having two slaves
> configured differently makes no sense since you don't know which request
> will end up with which slave. If you don't want to use connection oriented
> mode for some reason, you will need to configure the slave for each request
> with metadata.
>
> > > > configNeeded signal not configurable, I think that this is a
> > > > important point of extension, e.g. what if configuration is created
> > > > dynamically when the host is hit, not before.
> > >
> > > What do you mean with "hit"?
> >
> > when the address is resolved, before the connection is activated, but
> > what I really mean here is that you have to redesign the way a slave
> > asks for informations, e.g. login/password, cookies, etc., and all data
> > that a slave may needs, but you can't handle before it actually asks
> > for.
>
> Well, it doesn't _ask_ for cookies. Cookies always have to be send upfront
> (and your application can provide them so that they aren't fecthed from the
> cookiejar). I'm not sure how the login/password stuff is doing, I'm sure
> Dawit can provide you with a way so that your application can intercept the
> login/password request.

Hi,

Indeed I can and will add such support before 2.2 final release.  It requires some
changes in a few places, but it is not difficult todo.  

Anyways, I guess on the specific issues you (Sergio) point out, I can say that it is
something that has already been discussed before and put on a TODO list for 3.0.
Specially, the issue of moving all the user-interaction stuff out to the application
level such that the kio does not have to deal with it.  It is has been a big headache,
especially for David, to deal with KIO's ui_server :) However, such change is not
possible in 2.x series because it definitely would require API changes some of which
I am sure are not binary compatiable!

Regards,
Dawit A.
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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