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

List:       kde-core-devel
Subject:    Re: Implementing kioslaves for archive formats
From:       Roberto Teixeira <maragato () conectiva ! com ! br>
Date:       2001-07-25 18:20:00
[Download RAW message or body]

Em Qua 25 Jul 2001 14:44, David Faure escreveu:
> 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).

Hmm... I had noticed the difficulties in chaining the slaves, but I thought 
it was just lack of know-how on my part.

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

Yes, we talked about a KArchive not long ago IIRC, but somehow I thought 
maybe kioslaves might be better because ...

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

... I think it would be great to make it transparent to an application the 
fact that it was working on an actual file in the local fs or on a file 
inside an archive (something like a KURL "tar:/foo/bar"). I thought it would 
be relatively easy to implement with kioslaves. Guess I was wrong.

> 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 :)

Hmm... maybe I should take a loot at this idea.

. o O ( I thought a kio_tar would be so cool... )

regards,

	Roberto.

-- 
Roberto Teixeira, maragato@conectiva.com, maragato@kde.org

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