I remember the days when apr was operating system abstraction layer, and apr-util was the bunch of platform independent code where one could eventually decide which key/value dbm (beside provided sdbm) and bundled subset of expat. And then there was apr-iconv
When asking why can't we put some of the cool apr-util stuff like buckets, date, queue, etc ... to apr, there was a strong dislike "because that's not OS abstraction stuff" Anyhow, back then apr-util could be still build without any external dependencies (apr_xlate should have always be a part of apr-iconv, but no one listened) Then, at some point of time, apr-util introduced modules and become wrapper around third party libraries. Suddenly it got bloated to extremes. It become a dump spot for whatever database, crypto library ... whatever wrapper. OTOH, Apache Httpd uses for its core modules stuff like libcurl that has its own OS abstraction layer. IMO, all that third party library wrappers should not be part of apr. Anything from apr-util can go to apr (as it should in the first place), but all those dbm, db, odbc, ldap or whatever providers should go as separate apr projects. Basically for 2.0 we should have apr/apr (the real stuff) apr/apr-my-fancy-dbm-module1 apr/apr-my-fancy-dbm-module2 apr/apr-my-fancy-crypto-library apr/apr-iconv :D Since I already know, none of that will be accepted, please don't bother to convince me that I miss the point. OK ;) Regards -- ^TM
