2009/8/1 A. Walton <awal...@gnome.org>: > On Sat, Aug 1, 2009 at 1:54 PM, Mikkel Kamstrup > Erlandsen<mikkel.kamst...@gmail.com> wrote: >> 2009/8/1 Bastien Nocera <had...@hadess.net>: >>> On Fri, 2009-07-31 at 21:17 +0100, Alberto Ruiz wrote: >>>> 2009/7/31 Brian J. Tarricone <bj...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list