apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: APR 2.0 proposals
Date Sat, 24 Nov 2007 20:45:49 GMT
On Fri, 2007-11-23 at 10:37 +0000, Joe Orton wrote:
> ** 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.

Sounds good.

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

DBD libraries already are, so if it's technically possible, why not.

> ** 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?)

Buckets are useful outside httpd, IMHO. Ditto ldap. Probably other
features as well.

I think the only criteria here should be that it has to have no users.
But then again, how does one figure that one out?

So, I'd be inclined to keep stuff rather than chuck it. After all, if a
lot of stuff becomes dynamically loadable, there is no harm in larger

> ** Third proposal:
> Goes without saying: break API/ABI with wild abandon (ish).



View raw message