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

List:       kde-core-devel
Subject:    Re: Implementing kioslaves for archive formats
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-07-25 17:44:50
[Download RAW message or body]

On Wed, Jul 25, 2001 at 11:51:11AM -0300, Roberto Teixeira wrote:
> Dear David,
> 
> I am in the process of completely rewriting ark, _the_ archive utility, and 
> decided that maybe kioslaves are the way to go.

Let's discuss that :)
It's an important issue -> cc'ing kde-core-devel.

> Since I don't have all the experience you have, I decided to ask the 
> you. Do you think that it is a good idea to implement an ioslave for 
> an archive? I believe it is, but maybe you have a reason why it's not such a 
> good idea. The way I see it, a kioslave for a tar, for instance, would allow 
> us to use a tar as if it was a virtual file system or something, we would be 
> able to upload and download, list files, etc...

Yes but you wouldn't be able to do that on a remote tar file.
For such a case you need to chain the kioslaves, which... currently
doesn't work with filesystems-like structures (only with compression filters)
and is very inefficient (you can't really make sure the file gets downloaded
only once).

The way I was rather moving, was to do the uncompressing/compressing
and the open-the-tar-file all in process. If you check KFilterDev in kdelibs/kio
and its filter modules, you'll see that they are modules loaded in-process.
Same thing for KTarGz.

IMHO the best solution would be to write something like a KArchive class,
maybe inspired from the KTar API (although it lacks update/insert/remove
and that kind of thing - no idea how 'tar' does that stuff),
and to have KTar inherit from it and implement it,
and to have other implementations of KArchive in ark [at least until
some other apps need support for those formats].

The one thing that's also missing in kio currently, is to have some API
that allows using a karchive and/or a kfilterdev automatically, so that
application can simply say "I want to see this file" and the uncompression
happens automatically if it's compressed,
or "I want to browse this directory" and the opening-the-tar-file happens
automatically. Some sort of a new layer _on top_ of KIO.

In both cases (ioslaves or in-process karchive) we have a generic, modular
framework, so this doesn't speak for which solution to chose.
The advantages of the solution I suggest would be the speed (all in process), 
the stability, and a bit more control on how things happen (e.g. making sure
that a remote tar file gets downloaded only once).
The disadvantage is that applications would have to be 'ported' to the new
API for reading a file, i.e. using a QIODevice provided by the framework (kio),
which would automatically be either a QFile or a KFilterDev.
And for listing a directory... hmm, maybe we could have a ListJob-inherited clas
s
that would use KArchive internally, instead of an ioslave. This way we could
keep the same API, but have the job read from an archive instead. Hey,
never had that idea before, I think it's cool :)

Well, that's my view on it... I guess some people might prefer to do everything
as kioslaves instead, so it's open for discussion :)

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://www.mandrakesoft.com/~david, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

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