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

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

On 07/31/2009 01:59 PM, Mikkel Kamstrup Erlandsen 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.
>
> The prime benefit of having dedicated classes over your approach is
> having syntactically ensured that you are indeed working with GZipped
> buffers. Personally I like that, but this is of course 100%
> subjective.

Well, sure, but otherwise you can end up with classes for gzip, bzip2, 
zip, 7zip, rar, etc.  That alone is 10 extra classes, and I'm sure there 
are other compression schemes people might want classes for.  That 
sounds messy to me.

Having a constructor for a generic class that takes a parameter for the 
compression type would give you what you want, assuming it's set up so 
it returns an error if the content you pass it doesn't appear to be of 
the selected type.

I guess it doesn't really matter either way.  You could even implement 
GCompressedInputStream as a sort of class cluster that returns a 
(private) subclass depending on the compression type, or have all 
(public) classes be a subclass of a GCompressed{In,Out}putStream class, 
and for all operations (except for construction) you'd call methods on 
the superclass.

And I think there's a benefit to support format auto-detection if the 
developer doesn't care what format the input is in.  That's possibly a 
little more difficult to do with explicit subclasses, though the 
class-cluster method would still work and yet maintain separate classes 
for each compression format.

	-brian