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

[Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>]

2009/8/1 A. Walton <awalton gnome org>:
> On Sat, Aug 1, 2009 at 1:54 PM, Mikkel Kamstrup
> Erlandsen<mikkel kamstrup gmail com> wrote:
>> 2009/8/1 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.
>>
>> Ok, taking Brian's ideas into consideration, how about this:
>> GCompressedInputStream (extrapolate to output streams yourself) is an
>> abstract base class. It has static factories:
>>
>> GCompressedInputStream*
>> g_compressed_inputstream_new_for_type (const gchar* type_name);
>>
>> GCompressedInputStream*
>> g_compressed_inputstream_new_for_stream (GInputStream* in);
>
> More like
>
> GInputStream *
> g_compressed_input_stream_new (GInputStream *in);
>
> g_compressed_input_stream_new_for_type(GInputStream *in, const gchar
> *type)

Right. I was a bit fast to hit send there :-) And the
Compression*Stream would extend the Filter*Stream base classes.

> SNIP
> ... interface which G(G,B)Zip(I,O)Stream implements with the actual
> implementations hidden like GLocalFile; what public methods would
> those have anyways? (Not rhetorical, curious).

Compression level for GZip comes to mind. There are probably other parameters.

I think that the static factory approach hiding the actual impl. is
good, but I would also like to expose a GZip*Stream directly.

> Also, Zip is probably not a good idea since you'd have to deal with
> virtual files and crypto. Makes better sense as a GVFS backend I
> think.

Yeah, archive files require another approach. When we have finished
the pure compression formats we might also have a better idea whether
or not it makes sense to create a similar framework for the archive
formats.

-- 
Cheers,
Mikkel