apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: The case for apr-util-2.0
Date Thu, 06 Jun 2019 09:04:05 GMT
On 06 Jun 2019, at 07:07, Mladen Turk <mturk@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
—


Mime
View raw message