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

[Christian Dywan <christian lanedo com>]

Am Fri, 31 Jul 2009 15:07:10 -0700
schrieb "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.

I like the idea of a generic class and only supplying a MIME type, so
that different compression implementations can go in a separate package
just like GVfs backends today. It makes me think of gzip.GzipFile in
Python which I like because it lets you use a compressed file just like
a plain file, albeit I miss the autodetection there, so I second having
that feature in GCompressedInputStream.

Just my 2 cents,
    Christian