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
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:
- 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
expat.
- 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.
Regards,
Graham
--
