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

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.
> 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

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



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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]