On Wed, Jun 1, 2011 at 18:37, Graham Leggett <[email protected]> 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. Cheers, -g
