apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Proposal: splitting APR and former apr-util libraries
Date Wed, 01 Jun 2011 22:37:45 GMT
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.

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

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  

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:

- APR proper would be the Apache Portable Runtime, offering low level  
API compatibility, and nothing more.

- Users of APR proper would never need to worry about transitively  
depending on libraries other than the core system libraries, such as  

- People wanting to add new types of portability APIs can do so  
without code bloat in APR proper being a problem.

- If apr-foo becomes abandoned, it can be sent to the attic in the  
normal way. This will solve wrowe's issues with the LDAP APIs, using  
established ASF practice.


View raw message