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

["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) isn't a bad idea either, since you could specify the type at
construction rather than force mime auto-detection which could be a
pain (thinking network streams). Probably should do better than "_new"
if we go the interface route. This is how all of the other filter
streams are specified in GIO, IMO it's pointless to diverge much here.
Also wonder if it makes sense as a base class or whether it should be
an 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).

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.

-A. Walton

>
> We have concrete classes for the most used compressions publicly
> available, eg. GZip, Zip[1] (and BZip2?). Other compressions can be
> registered via GIO extension points (one for compressors and one for
> decompressors).
>
> --
> Cheers,
> Mikkel
>
> [1]: Modulo the fact that Zip files can't be parsed as simple streams.
> Maybe a GArchive*putStream base class is needed.
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list