apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Proposal: splitting APR and former apr-util libraries
Date Wed, 01 Jun 2011 23:27:20 GMT
On Wed, Jun 1, 2011 at 18:37, Graham Leggett <minfrin@sharp.fm> wrote:
> Hi all,
> A while back, the apr and apr-util projects were combined into a single
> project, however this amplified a problem we have been suffering for a
> while.
> APR attempts to provide portable access to the following:
> - Low level APIs, such as memory management, file access, process/thread
> handing, etc, relying on basic OS functionality provided by glibc and
> friends.

This is what "apr" used to be.

> - High level APIs, such as XML parsing, dbm and friends, SQL database and
> LDAP drivers, and crypto, relying on specific libraries providing each
> service.

And this is what "apr-util" used to be.

> The problem with mixing the two together is that many applications only care
> about the low level stuff, they don't want to link to BerkleyDB or expat
> just to get access to APR pools. This problem was in turn made worse when
> apr and apr-util was combined. It made sense that basic APIs like base64,
> date handling, string handling, etc should have moved to APR from apr-util,
> but what didn't make sense was moving everything.
> Some APIs, such as the dbd SQL library, the LDAP library and the crypto API
> can be separated out from APR at build time on some platforms, and this is
> done by vendors like Redhat, who ship a range of APR packages containing the
> parts you need. This doesn't go far enough.
> What I propose is that we take the APIs in the second group, including but
> not limited to XML, dbm, dbd, ldap and crypto, and spin these out into
> specific dedicated projects of their own under the APR umbrella, with their
> own release cycles, tags and branches. This would solve the following
> problems:

You're just talking about bringing back apr-util.

Making these N different packages doesn't do much beyond just what the
old apr-util did. I guess it solves a bit of dependency stuff.


Personally, I gave up on the "combined vs split" argument a long time
ago. This community wanted to combine everything, and I felt
differently. It happens. I also felt that APR has got a lot of old,
clunky code that needs to be cleaned up. As a result, I started my
PoCore project to deal with just the low-level portability concerns,
with a full revisit of all the concepts based on experience with APR,
HTTPD, svn, and serf. High-level stuff can be left to applications or
other third-party libraries.


View raw message