On 06 Jun 2019, at 07:07, Mladen Turk <mt...@apache.org> wrote: > 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.
Remember that platform abstraction is valid both at the lowest level OS layer where we’re trying to make files work, and the higher layers where we’re trying to make databases work. > 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 +1. We have a basic underlying library that underpins everything, and then on top of that “libraries that use the underlying library, that provide abstraction services above”. The problem of abstracting away platforms should be an ecosystem of libraries under the APR project umbrella, not one monolithic library. Regards, Graham —
smime.p7s
Description: S/MIME cryptographic signature
