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

List:       kde-core-devel
Subject:    Re: KIOSlaves
From:       David Faure <faure () kde ! org>
Date:       2000-01-20 19:47:01
[Download RAW message or body]

On Thu, Jan 20, 2000 at 06:14:39PM +0000, Stephan Kulow wrote:
> Waldo Bastian wrote:
> > 
> > On Thu, 20 Jan 2000, Stephan Kulow wrote:
> > > Waldo Bastian wrote:
> > > > On Thu, 20 Jan 2000, you wrote:
> > > > > Waldo Bastian wrote:
> > > > > > Hi Stephan,
> > > > > >
> > > > > > What is the status of the IO-slaves in the make-it-cool-branch?
> > > > > > What is working and what isn't? What needs to be done before it
> > > > > > can be merged with the head branch?
> > > > >
> > > > > Well, what is lacking most is a developer friendly API for
> > > > > KIOJob.
> > > >
> > > > The API beteen KIOJob to the application or the API between KIOJob
> > > > and the io-slave?
> > >
> > > Between application and KIOJob, KIOjob should internally use KIOSlave
> > > to handle it's own commuication to the slave.
> > 
> > The current API isn't that bad isn't? The major problem of today's
> It is! 
> 
> > IO-slaves seems to be the copying stuff which needs to be done in the
> > slaves themselves. I thought the idea was to move the recursive
> > copying/moving stuff to KIO. That would mean a change in the API
> > between KIOJob and the KIOSlave.
> Which has already been done. Just the recursive copying/moving has to
> be resetup in libkio.
> > 
> > What needs to be changed in the API between KIOJob and Application?
> In general: no reuse of KIOJob. a KIOJob should be _one_ job, not
> thousands.

This would sound right, but isn't that a problem for keeping e.g.
FTP connections between requests ? That's why we have a pool
currently, right ? Or do we want to have a pool of connections on one hand,
and one-shot jobs on the other, the jobs taking a connection in the pool ?
This would solve the problem, right ?

> David and I haven't made up if it's better to have several subclasses
> or if one class is enough. But in any case you need subjobs that need
> to be finished before a job can finish, etc. The application shouldn't
> have to care at all about this. And if you look at Kurt's (excellant
> and accurate) tutorial to kioslaves, you'll find out that the API
> described there sucks.
I remember feeling the same, but I'm not sure why anymore.
What should be changed in the external API ?

> The current kiojob is not the way it should be, it's just the way it
> happened
> to be. For example Lars demanded that you can issue several jobs at the
> same
> time without caring and giving priorities on the importance on the jobs 
> (the stylesheet should be there before the images). This is a very
> important
> demand and I would expect something like this from a good IO-lib. But in
> the
> current KIOJob this wouldn't be possible without major hacks.

Some random thoughts from this :

The app still creates a KIOJob, but each job created doesn't
start on its own, it's managed by a scheduler.
This is not yet done, is it ?



> Something that has to be thought out quite well is what (and how) to
> display in the progress to the user.
> The way it used to be (the slaves themself
> decide which informations are important) can't be the way to go.
For recursive stuff no problem, that will be in libkio. For stuff
like copying one file, if libkio handles progress information, it means
it has to see all data come through. Well it does anyway, since it
receives it from the slave. This shouldn't be a problem, then ?

> I would love to spend a week fulltime on this, but I won't have this
> week too soon ;(
:( I lack time as well, and ideas - seems you've already thought quite
a lot on this... whereas I'm only starting.

-- 
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]