apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <minf...@sharp.fm>
Subject Re: APR 2.0 proposals
Date Fri, 23 Nov 2007 10:51:19 GMT
On Fri, November 23, 2007 12:37 pm, Joe Orton wrote:

> 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.

I have used APR in some commercial projects, and these have used apr
exclusively, and not apr-util, so this isn't the case everywhere.

> 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.

It sounds reasonable, if it can be made to work (which is probable).

> ** 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.

This implies that we have some way of knowing which parts of apr-util are
not used outside of httpd, and ever since APR stood on its own two feet
and became a system library, this has become impossible to measure.

As an independant end user of apr, had I to learn that apr v2.0 was
planning to randomly drop features I was using because some random project
X wasn't using those features, my response would be to drop apr, or simply
not use apr 2 at all.

> 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.

How will we reliably determine whether a feature has no users? APR offers
some very simple, straightforward APIs, "silence" on a particular feature
could be an indication that the feature works very well, not that it is
unused.

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

When "get rid of" means "move to apr-buckets, apr-ldap", etc as per first
proposal then sure.

Regards,
Graham
--



Mime
View raw message