[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 18:14:39
[Download RAW message or body]

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.
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. This is almost as reading how to use a file dialog in gtk!
:)

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.

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.

I would love to spend a week fulltime on this, but I won't have this
week
too soon ;(

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]