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

["Brian J. Tarricone" <bjt23 cornell edu>]

On 07/31/2009 01:17 PM, 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.

Eh, they can be optional, or dlopen()ed at runtime.  The API could be 
flexible enough (using the existing 'extension points' architecture) to 
allow people to add their own implementations for their own use, or some 
interested party could bundle a set of them in another package... though 
in that case the entire compressed stream class could be in a separate 
library.  Instead of using an enum to select the compression type, a 
string identifier could be used instead (perhaps the mime type).

IMO optional deps aren't really a big deal.  If people thought it'd be 
useful to have one or two mandatory deps (say zlib and bzip2, for 
example), that might be ok too, since they're pretty ubiquitous.

	-brian