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

List:       kfm-devel
Subject:    Re: RE: FW: kdebase/kioslave/info
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-02-28 22:50:39
[Download RAW message or body]

On Mon, Feb 28, 2000 at 10:45:08PM +0100, Waldo Bastian wrote:
> On Mon, 28 Feb 2000, David Faure wrote:
> > On Mon, Feb 28, 2000 at 08:44:45PM +0100, Waldo Bastian wrote:
> > > On Mon, 28 Feb 2000, you wrote:
> > > > Hmm, closeConnection emits ready().
> > > >
> > > > Do you need that ?
> > >
> > > No.
> >
> > OK.
> >
> > > > grep says that closeConnection is not used yet, but whenever
> > > > it will be (I guess you plan to use it ;-), do we need ready() ?
> > > > I guess so...
> > >
> > > Why?
> >
> > Dunno. It's hard to imagine your code.
> > But I thought you wanted to know when the slave had finished
> > closeConnection() for instance to avoid calling the next
> > openConnection on it too early (think about kio_ftp which is waiting
> > for the result of a command...)
> 
> That's no problem. It will be queued in the socket. When the slave is 
> ready he will find the next command waiting for him (her?).

Yes but as I said the slave might have to wait for the result of
a command, i.e. for a signal, i.e. it _IS_ ready to read on the socket....

> > > > In terms of naming, though:
> > > > all commands emit finished(), openConnection emits connected(),
> > > > perhaps closeConnection should emit disconnected() or so.
> > >
> > > Maybe we should rename openConnection to "setHost". At least HTTP
> > > doesn't make connections at all in openConnection. And from what I
> > > understood SMB doesn't either.
> >
> > Well, what would closeConnection become then ?
> >
> > Isn't open/close right in terms of what the scheduler sees ?
> > Of course non-connection-oriented-protocols don't do anything
> > and just use the connection information in get() or whatever.
> 
> The scheduler has no strong notion of connections. It does have 
> accurate information about the host the slave should use and it has a 
> clue whether the slave is still connected to that host or not. (But it 
> doesn't know for sure).

Yup (reminds me that kio_ftp should detect timeouts...)

> Wrt to the scheduler it is up to the slave to make/break connections 
> when it needs.
> 
> If we want to have real "Connection-oriented" mode of operation I 
> suggest the following:
> 
> setHost( host, port, user, password);
> openConnection() // Opens a connection and puts the slave in
>         Connection-oriented-mode.
> closeConnection() // Closes any existing connections. Puts slave back 
>         in Connectionless-mode.

This sounds right.

> The scheduler then only uses 'setHost()'. If an application wants to use
> a slave in Connection-oriented mode it has to call "openConnection()"
> in the slave (after the scheduler has done a "setHost"). 

Well, it's not only the application that decides.
With FTP you have no choice, it only supports connection-oriented mode.

Do we have to add that to the .desktop of each protocol ?
Otherwise, how will the scheduler know whether to call openConnection
or not ? (still thinking about FTP)

> If the slave operates in Connection-oriented-mode it will not make 
> connection automatically.
I don't get that.

> If the connection dies and the application 
> makes a request which requires a connection, the slave returns with an 
> error.
> 
> The other thing which we need for this Connection-oriented-mode is to 
> be able to allocate a slave and to use it for multiple jobs without 
> returning the slave to the scheduler. I think this means that jobs like 
> "get", "put" and "delete" should be overloaded with a version which 
> takes a slave as argument. When the job is finished the application can 
> reuse the slave. (Instead of the slave being returned to the scheduler).

Sounds right.

> Such a Connection-oriented-mode would typically be used by 
> mail-programs or a 'ncftp'-like program.
> 
> Cheers,
> Waldo

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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