On Thu, 20 Jan 2000, 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 ?

The old slaves already had that. The "pool of connections" is 
represented by the pool of io-slaves. When a new job is created we look 
for an io-slave with a (possibly) matching connection.

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

Does Lars has an idea how to implement this? I can imaging two ways:
* Queue requests without actually starting them before all higher 
priority requests have been finished. (This is easy)
* Throttle, e.g. tell an IO-slave not to receive any data or to receive 
not more than XX bytes/sec. (This sounds difficult)

> > 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 don't think so.

Cheers,
Waldo