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