Re: [boost] Re: Anyone planning a compression library?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-02-15 14:59:11

At 06:55 PM 2/15/2001 +0100, Jens Maurer wrote:

 >Jeff Garland wrote:
 >> I'm thinking (and hearing) that the way to go would be to use zlib on 
the
 >> platform if it exists, and deliver it as a detail for those platforms
 >where it
 >> doesn't (essentially Peter's suggestion).  This avoids any extra
 >downloading and
 >> means the maintenance means paying attention to zlib releases and
 >upgrading the
 >> boost detail as needed.
 >
 >I would like to point out that the full boost_all.zip is already >2 MB
 >compressed (500 KB of which are JPEGs of developers) and the Info-ZIP
 >stuff adds another 200 KB compressed.
 >
 >Compare that to the full Linux 2.0.30 kernel, which is only 6 MB.
 >
 >> I doubt they would want to do this.  zlib is a C library which is used 
as
 >a
 >> basis for compression libraries in C, JAVA, and LISP (at least).  So 
I'm
 >sure
 >> they would view a boost C++ adapter as another example of a layer on 
top.
 >
 >Yes, that's my impression as well.

Yes, those are all valid points.

So what's the solution?  We really don't want to reinvent the wheel.

There must be some limited set of circumstances when it would be 
permissible for a Boost library to depend on some other library.  The 
Python example is a good one; anyone using it will expect to have Python 
installed.

Imagine this.  Boost gets larger, and we break the download up into several 
pieces.  Say a base section, a graph section, an numerics section, and a 
compression section.  On the download page, these are presented in a table 
with a link to click on to download the section you want.

For the base and graph sections there would be no other links.

For the compression section, there would be one additional link (with 
explanation of why) that downloads the zlib distribution from their ftp 
site.

For the numerics section, there might be a couple of links, to a couple of 
non-boost numerics libraries.  Perhaps explanation of exactly what you 
won't be able to link if you don't download them.

Presumably part of the formal review for any library that depends on a 
non-Boost library would include pros and cons of the dependency.  Thus 
there is a protection against a detrimental dependency on a non-boost 
library, but a mechanism to avoid reinventing the wheel if linking to 
another library really is the smart thing to do.

I'm just thinking out loud, not advocating a position.

--Beman