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

[Bastien Nocera <hadess hadess net>]

On Fri, 2009-07-31 at 21:17 +0100, Alberto Ruiz wrote:
> 2009/7/31 Brian J. Tarricone <bjt23 cornell edu>:
> > On 07/31/2009 05:48 AM, Mikkel Kamstrup Erlandsen wrote:
> >
> >>  From the looks of it, it should be straight forward to write
> >> GZip{In,Out}putStream classes based on zlib
> >
> > I'd say call it GCompressed{In,Out}putStream and have it either auto-detect
> > the compression type, or have a param in the API to specify from an enum (or
> > both).  People can add support for other types of compression as time goes
> > on.
> 
> And expand the list of glib dependencies to the infinite?
> I don't think I like such an idea at this level of the API.

You could claim the same about the gdk-pixbuf loaders, or the gvfs
backends. The point is that you'd want to make your original class
flexible enough that people could extend upon it (even if you don't
start off with a plugin API).

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

I'd be happy seeing at least the first one, very happy to see the first
3, that all have open source implementations, and would provide more
robust support for those file types in applications.