> On 6 Jun 2019, at 06:07, Mladen Turk <mt...@apache.org> wrote: > > 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
You said it yourself. Dependencies already in apr-dbm! > 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" An "insider" view. For the outside world, the apr/apu split achieved very little beyond mild confusion. The whole package is, after all, still pretty small in the global scheme of things. Having said that, reversing the split from where we are now could just be more confusion. Ho, hum. > 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) Um, in the same sense it still can. ldap and dbd are just as optional as dbm! > 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. Yes, it has modules. We even introduced dynamic loading of the apr_dbd_foo modules, though perhaps that was somewhat half-baked. > 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. I think you're arguing for fully-baked apr modules, yesno? > 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 ;) Can't speak for others, but I'm neither accepting nor rejecting that. I believe our downstream packagers already serve apr as modules: e.g. https://packages.debian.org/search?keywords=libaprutil1 shows apr-dbd-foo and apr-ldap separated out. If you're proposing to extend that to other dependencies and even apr_iconv, I doubt anyone will object. And if you want to open it, like httpd, to third-party modules, that would indeed look rather interesting. Though I doubt there would be so many takers as with something more visible like httpd! -- Nick Kew
