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