apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject APR 2.0 proposals
Date Fri, 23 Nov 2007 10:37:06 GMT
** Key proposal: "one tree, multiple libraries"

Justin has long argued that there is no point in having apr and apr-util 
as separate trees since everyone uses both or neither, and I agree.  The 
fact that every downstream application picks up depdendencies on half 
the third-party libraries in existence by linking against apr-util - 
regardless of whether or not the app uses them - is also a real problem.

I think the way forward is to consolidate apr and apr-util into a single 
tree, but where the code exposes a dependency on a third-party library, 
build that code into a separate library.  So along with libapr, you get 
a libapr-dbm for the DBM code, a libapr-xml for the XML code, etc.  (I 
know various people have talked about various things along these lines 
before; not claiming this is an original idea! ;) 

apr-config is extended to expose a new interface to select which 
sub-libraries an app wishes to link against.

Question: could the sub-libraries become optional-to-build?  Not sure.

** Second (more controversial/radical?) proposal:

Reduce the consolidated libapr library size by chucking out everything 
from apr-util which has been around for N years and is not used outside 
httpd.  Anything that is used only by httpd should be moved to the httpd 
tree, no point everyone else being burdened by it.  Also chuck out stuff 
which has *no* users at all.

Impact: maybe gets rid of apr/random/, apr-util/buckets/, 
apr-util/ldap/, half of apr-util/misc?  (If/when httpd moves to the serf 
buckets model maybe buckets can go away completely?)

** Third proposal:

Goes without saying: break API/ABI with wild abandon (ish).

OK, flame on.


View raw message