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

[Tomeu Vizoso <tomeu sugarlabs org>]

On Fri, Aug 14, 2009 at 22:38, Shaun McCance<shaunm gnome org> 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.
>
> It's nice to see I'm not the only person that's after this.
> I'm not sure what other people need this for, but I thought
> I'd give a data point for why it's useful to me.
>
> Yelp currently has its own subclass of GIOChannel that does
> decompression on the fly for gzip, bzip2, and lzma.
>
> http://git.gnome.org/cgit/yelp/tree/src/yelp-io-channel.c
>
> It's not a particularly elegant solution.  It has everything
> in one file, with bzip2 and lzma functionality in #ifdefs,
> and determines what to do by file extension.  But it does the
> job for Yelp, which needs to read man and info pages that may
> be compressed.
>
> (It's also a fairly trivial and not-complete implementation.
> For instance, it doesn't do seeking, because Yelp doesn't
> need it.)
>
> I've been looking at converting Yelp over to GIO, so having
> such an InputStream would be very useful to me.  If it's not
> in GLib, I'll have to do my own.
>
> I'd really need all three of the above compression schemes to
> work.  If a gzip-only InputStream is done, I can always ship
> my own bzip2 and lzma implementations.
>
> A flexible system using runtime-loadable backends is fine for me,
> as long as I know bzip2 and lzma implementations are available.
> I don't particularly care about having a guarantee that they're
> there.  Distributions that ship lzma-compressed man pages can
> just make sure the backend is installed.  Not my problem.
>
> And yes, this is me volunteering to do the work, but not until
> I get around to gutting Yelp, which will be in maybe two months.
> I'll have to do the work anyway for Yelp.  It would be nice to
> get input from the maintainers about what approach they think
> is best.

FWIW, Sugar uses zip quite extensively to bundle content and software
and we would love to move from using python's zipfile to something
glib-based.

Have no resources to offer, but I will tell people interested on
working on bundles to consider helping out with this.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning