> > 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.
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.
--
Shaun
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
