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

[Tomas Bzatek <tbzatek redhat com>]

On Mon, 2009-08-03 at 07:58 -0400, Freddie Unpenstein wrote:
> From: Steve Fr-23;cinaux, Date: 03/08/2009 19:38, Wrote:
> 
> > Bastien Nocera wrote:
> > > I could think of at least 5 types of compressions that would be
> useful
> > > to have without having to use a command-line tool to decompress:
> > > - gzip for anything and everything that can come from a web server
> (in
> > > my case, iTunes Music Store playlist parsing, or more widely,
> GOffice
> > > file formats)
> > > - zip for OpenOffice.org documents and Comic Books (evince)
> > > - 7zip/LZMA/Xz formats for Comic Books
> > > - Rar for the same as above
> > Aren't there two classes of file types there ? Compression vs
> Archiving
> 
> Archiving formats would be better supported by GVFS, wouldn't they...?
> Treating an archive as a virtual directory.
> 
> 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). There may be some value to
> supporting those compression formats even without supporting the
> entire archive format. The compression is pretty much the hard part of
> handling these archives.
> 
> 
> Going the extra step further, though, the next obvious idea would be
> to do the same thing that gunzip does when you concatenate together a
> series of gzipped files - it simply returns the uncompressed content
> of each file sequentially.
> 
> 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.
> 
> The ability to manipulate archives as well as simple compression would
> be fantastic. I did at one stage need to apply a "filter" to the files
> matching a certain mask within a tgz archive. With support like that,
> I could uncompress the tgz, split the tar, pass through files I'm not
> interested in, apply the filtering to the ones I am, and then
> repackage and re-compress the lot on the way out, without having to
> mess around with spawning external commands and correctly handling the
> myriad of things that can go wrong.
>