Re: GZip{In,Out}putStream in GIO?

[Tomas Bzatek <tbzatek redhat com>]

On Mon, 2009-08-03 at 07:58 -0400, Freddie Unpenstein wrote:
> Archiving formats would be better supported by GVFS, wouldn't they...?
> Treating an archive as a virtual directory.

We already have gvfsd-archive for some time, based on libarchive, able
to handle TAR and ZIP archiving formats with GZIP, BZ2 compression,
easily extendable to LZMA and XZ (available from libarchive, not yet
enabled by default in gvfs).

> However, zip has a few compression formats, rar compression can be
> applied both before and after bundling of the files (a rar "solid
> archive" is similar to a tar.gz archive).

Remember we can't build anything around RAR format due to incompatible
licensing, except of the file-roller way (spawning external commands).

> I guess, though, you still need to understand the archive format, for
> at least some of those formats. So I suppose some kind of archive
> handler would be needed to pick out the individual streams for
> concatenation. Given that, reading a zip file as a compressed stream
> could instantiate a concatenation object that sets up the appropriate
> archive handler and just iterates over the available files, joining
> the uncompressed data of each individual decompression stream together
> as a single continuous stream. Which would give you the option to set
> up the archive handler yourself and extract the one(s) you want
> individually. This would be a boon even for gzipped files, giving you
> the option to extract concatenated compressed streams individually
> rather than as a solid indistinguishable stream.

libarchive can be easily used as a "filter" between two streams,
transparently decoding incoming data. This should be really implemented
as an extension, we don't want to have another dependency in glib.


P.S.: sorry for the previous empty e-mail, key shortcuts are sometimes
dangerous in Evolution...
-- 
Tomas Bzatek <tbzatek redhat com>