Re: RFC: Adding zlib dependency to libgio

[Shaun McCance <shaunm gnome org>]

On Mon, 2009-11-09 at 12:17 +0100, Alexander Larsson wrote:
> On Sun, 2009-11-08 at 12:01 +0100, Martin Nordholts wrote:
> > On 11/08/2009 10:54 AM, Alexander Larsson wrote:
> > > I've been working on some API for gio (more details later) that involves
> > > having an API for (de)compression. Having this as a public API makes
> > > zlib a mandatory dependency for libgio (and thus the glib tarball).
> > 
> > Hi,
> > 
> > Will there some kind of plug-in architecture so it is possible to add
> > say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib
> > dependency also be made optional? Not that I see a problem with a
> > mandatory zlib dependency.
> 
> The API in question includes compression and decompression as streams
> (among other things), and is pluggable. Code to do automatic detection
> of compression type could easily be added.
> 
> However, having some level of support being guaranteed (i.e. a mandatory
> dependency) has additional value that something being pluggable doesn't.
> For instance you could distribute zlib compressed data (as file or
> linked into your app) and depend on all glib installations being able to
> decompress that data. It also means you can e.g. design file formats
> based on a specific compression algorithm and never run into issues with
> some platform not having what is needed to read the file.
> 
> Plugin-based optional compression support is basically only useful for
> best-effort decompression of "unimportant" document files. Thats
> obviously nice to have, but not as important as reliable compression
> support.

That sounds fair.  Right now, Yelp will happily build without
bzip2 and lzma support if you don't have them.  I consider it
a distro problem: if distros want to ship man and info pages
compressed with bzip2 or lzma, then they need to make sure
their Yelp is built right.  I have no problems pushing that
policy decision lower.

How do you envision the optional extra support being provided?
Would there be extension points that GVFS could plug into?  Or
compile-time optional modules like the GdkPixbuf loaders?  Or
would applications be expected to provide the extra juice?

I'm willing to do the grunt work to add these.  It's work I'd
have to do in Yelp anyway to fully transition to GIO.  Thanks
for tackling the hard part of the problem.

--
Shaun