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

On Sun, Jan 30, 2000 at 02:35:00PM +0000, Stephan Kulow wrote:
> David Faure wrote:
> > 
> > On Sun, Jan 30, 2000 at 12:54:37PM +0000, Stephan Kulow wrote:
> > > Well, if you're doing a copy from ftp to file, you still need to create
> > > dirs, etc. in a central place. Doing slaves from slaves is bad for me,
> > > so it leaves the app and I don't think it's too bad. I buy the
> > > performance win, but I doubt it will be more than some percents.
> > 
> > Hmm, ok. You don't mention the ugliness of the code (handling this
> > asynchronously instead of synchronously), but I guess I'll have to live
> > with it.
> > 
> Well, we have to decide. doCopy is very hard to understand as it is
> and I doubt the way we do it now makes it easier to read :(

Yes, that's my point. It's a lot worse in the new way.

> The main question that arises to me is how you would do per protocol
> copying. With the help of the app or not? The kioslave isn't really
> an app in itself as it has no display connection (it looses it with
> the fork), so how would you start the other slave?
Ah I missed that point. I though we could still do that.

> The alternative
> with putting a lot into the slave code without duplicating is of
> course good one, but you have to do it right.
It's not really an alternative... If we do a lot in the slave, it has
to be able to launch another slave. Or it can't do much...

> For example del() and
> listRecursive are single-protocol methods, so they would make good
> examples of your way and I would suggest doing it now.

Yes, del() is easy.
But listRecursive is either in the app OR in the slave. For del, both work,
but for copy we need it in the app if a slave can't launch another one.
So listRecursive remains in the app... (see below)

> You could also make your code simpler in giving the slave a bunch
> of URLs to operate on and a common code let the slave operate one
> by one.
Well I thought of
mkdir ( QStringList paths )

but that sucks. Because for dirs that already exist, we want to show
the rename dialog, and if skip is chosen we have to remember it, 
and so on.

Hmm ... or the common code could do that, and return the list of
dirs to skip. Why not.

> But for move, this still makes
> listDir - transfer to app - make dirs in dest - getting each file
> - putting each file - del in source
> I don't think you can get around the get+put in the app, but this
> shouldn't be too complex (I hope)

get+put in the app is fine with me, it's all the rest that is hairy.

Ok, let's go for a bit more high-level methods, handled by common code.
del() could take a QStringList (and be called twice, once for dirs and once
for files) and call the slave's del for each.
Same for mkdir(), which returns the skip list...

A lot still todo ... and I'm leaving for NY soon.

Any takers ? :-)

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