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

List:       kde-core-devel
Subject:    Re: Idea for the new kio
From:       David Faure <faure () kde ! org>
Date:       2000-01-30 4:19:28
[Download RAW message or body]

More precisely, this would mean :

* Adding copy, move and del (in a recursive sense) to SlaveInterface
and SlaveBase (i.e. the slave's API).

For copy/move :
* Tell the src slave to do the copy/move
* This is handled by SlaveBase (not by the slave-specific code) :
  - It implements listRecursive by calling listDir directly.
  - It creates jobs for creating dirs to the destination (I was wrong, this is
    still needed - doing all in the dest slave solves this but means calling
    listRecursive on the src slave... i.e. more changes for nothing.)
  - It does the file transfer by doing a KIO::put and get here,
    a bit like Waldo's FileCopyJob but modified for "get here".
[I'm sorry - I should have thought about that before. Well you can't control
 sleeplessness...]


For del :
* This is handled by SlaveBase as well :
 - It implements listRecursive, calling listDir directly.
 - It calls the slave's implementation of delete directly.


The common code is still in one place, e.g. SlaveBase, but it's not
anymore in the application's process. Viewed from outside, it is
all ONE job, which the ioslave handles. The main point is that
it can do in a synchronous (blocking) mode, just like we did before.
Create a dir, _wait for completion_, create the next one, ...
Copy a file, _wait for completion_, copy the next one, ...
We can't do that in the app's process, which the code a lot more complex.

The other gain is performance, obviously. The source slave handles a lot
by itself (listing recursively, doing the gets) which reduces the amount
of communication with the main Job, and the scheduling...

The slave becomes again a bit "the master of the universe" as Stephan said,
but this is the only way to implement this complex stuff in a simple way
(synchronously).

[ To see what I mean by the not-so-simple way, look at 
 CopyJob::slotFinished(Job*). And a lot isn't there yet... It's doable, 
 but ugly to write and debug. Create a dir, the error-checking for it is
 _right before_ in the code, because called on the next slotFinished(). Hmm. ]

Technical note/question: is there an equivalent in the new architecture of
    while( !job.hasFinished() )
        job.dispatch();
This is how we used to do things synchronously (in a slave using a job)...

OK, I think I have given enough details. Comments please :-)

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