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

List:       kde-devel
Subject:    Re: IO-slave configuration
From:       Sergio Moretti <sermore () infinito ! it>
Date:       2001-05-17 9:46:51
[Download RAW message or body]

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?

> > 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. I think this could be the right place to handle it.
I'll try to make an example:
consider login/password case; now, when a slave find that it has to 
make a login, it calls openPasswdDialog and retrieve informations 
bypassing the application. I propose to move openPasswdDialog in kdeui 
(or whatever it fits), and to extend the configNeeded signal to handle 
this. Obviously this behaviour has to be controlled by a config entry 
that in the default state let things unchanged from now (from the 
application's point of view).
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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