apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject The case for apr-util-2.0
Date Thu, 06 Jun 2019 05:07:42 GMT
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

Mime
View raw message