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

List:       kde-core-devel
Subject:    Re: KIOSlaves
From:       Stephan Kulow <coolo () kde ! org>
Date:       2000-01-20 20:27:54
[Download RAW message or body]

David Faure wrote:
> 
> > > 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 ?
Yep. The class KIOSlave encapsulates the term connection quite well.
You have to make the connection between the one shot jobs and the
persistent
connections somewhere more central - as KIOSlavePool was before.
> 
> > 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 ?
See my other mail
> 
> > 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 ?
Nope. But this will have to be the first step and I'm willing to
implement
it basicly so I can finally switch for listing directories in kfile to
kio.
> 
> > 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 ?
Well, libkio has to decide this still. It can't display anything blindly
to the user - it doesn't make sense to display "getting file:/tmp/blah"
> 
> > 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.
> 
There is a lot a library like this can do to make the API simpler
instead
of making it just work. Currently writing applications using libkio is
as
hard as writing a slave (forget about how hard it is to actually write a 
slave :)

Greetings, Stephan

-- 
It said Windows 95 or better, so in theory Linux should run it
                                                GeorgeH on /.

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