You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Mladen Turk <mt...@apache.org> on 2019/06/06 05:07:42 UTC
The case for apr-util-2.0
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
Re: The case for apr-util-2.0
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jun 6, 2019 at 4:15 AM Graham Leggett <mi...@sharp.fm> wrote:
> On 06 Jun 2019, at 10:38, Branko Čibej <br...@apache.org> wrote:
>
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 18.04.2 LTS
> Release: 18.04
> Codename: bionic
> $ apt-cache search aprutil
> libaprutil1 - Apache Portable Runtime Utility Library
> libaprutil1-dbd-sqlite3 - Apache Portable Runtime Utility Library -
> SQLite3 Driver
> libaprutil1-dbg - Apache Portable Runtime Utility Library - Debugging
> Symbols
> libaprutil1-dev - Apache Portable Runtime Utility Library - Development
> Headers
> libaprutil1-ldap - Apache Portable Runtime Utility Library - LDAP Driver
> libaprutil1-dbd-mysql - Apache Portable Runtime Utility Library - MySQL
> Driver
> libaprutil1-dbd-odbc - Apache Portable Runtime Utility Library - ODBC
> Driver
> libaprutil1-dbd-pgsql - Apache Portable Runtime Utility Library -
> PostgreSQL Driver
> $ apt-cache show libaprutil1
> Package: libaprutil1
> [...]
> Depends: libapr1 (>= 1.6.2), libc6 (>= 2.25), libdb5.3, libexpat1 (>=
> 2.0.1), libgdbm5 (>= 1.14), libssl1.1 (>= 1.1.0)
> […]
>
>
> That looks like a packaging bug. This is on CentOS7:
>
> [minfrin@chandler ~]$ ldd /usr/lib64/libapr-1.so.0.6.3
> linux-vdso.so.1 => (0x00007ffee65c1000)
> libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f8d24138000)
> librt.so.1 => /lib64/librt.so.1 (0x00007f8d23f30000)
> libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f8d23cf9000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8d23add000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f8d238d9000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f8d2350c000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f8d24578000)
> libfreebl3.so => /lib64/libfreebl3.so (0x00007f8d23309000)
>
> [minfrin@chandler ~]$ ldd /usr/lib64/libaprutil-1.so.0
> linux-vdso.so.1 => (0x00007ffd83171000)
> libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f2813501000)
> libapr-1.so.0 => /lib64/libapr-1.so.0 (0x00007f28132c6000)
> libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f28130c1000)
> librt.so.1 => /lib64/librt.so.1 (0x00007f2812eb9000)
> libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f2812c82000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2812a66000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f2812862000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f2812495000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f2813962000)
> libfreebl3.so => /lib64/libfreebl3.so (0x00007f2812292000)
>
> I specifically object to libexpat, libssl, libdb and libgdm being on
> this dependency list ... the latter two are just bloat, but the former
> two create all sorts of problems for any project that happens to use
> either of them directly.
>
> +1.
>
> Looking at the archeology, this problem was identified years ago, and each
> successive addition has been properly modularised. What was needed was to
> go back and modularise the earliest additions.
>
It seems the latest additions are the only problem on apr-2.0;
$ ldd libapr-2.so
linux-vdso.so.1 (0x00007fc16a217000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fc16a136000)
librt.so.1 => /lib64/librt.so.1 (0x00007fc16a12c000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fc16a0f0000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc16a0ce000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc16a0c8000)
libssl.so.1.1 => /opt/openssl111/lib/libssl.so.1.1 (0x00007fc16a034000)
libcrypto.so.1.1 => /opt/openssl111/lib/libcrypto.so.1.1
(0x00007fc169d48000)
libxml2.so.2 => /lib64/libxml2.so.2 (0x00007fc169bde000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc169a18000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc16a218000)
libz.so.1 => /lib64/libz.so.1 (0x00007fc1699fe000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fc1699d5000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc169851000)
That would be a problem. Please fix, both yourself, and Nick. Also curious
where libz/lzma arrived from, I'm guessing libxml2, because libssl 1.1.1
build no longer includes compression by default.
We have a second problem, someone colored the names in a very inappropriate
way;
[wrowe@hub apr-2]$ ls *.so
apr_crypto_openssl-2.so
apr_crypto_openssl.so
apr_dbd_mysql-2.so
apr_dbd_mysql.so
apr_dbd_odbc-2.so
apr_dbd_odbc.so
apr_dbd_pgsql-2.so
apr_dbd_pgsql.so
apr_dbd_sqlite3-2.so
apr_dbd_sqlite3.so
apr_dbm_db-2.so
apr_dbm_db.so
apr_dbm_gdbm-2.so
apr_dbm_gdbm.so
apr_dbm_ndbm-2.so
apr_dbm_ndbm.so
There is zero excuse for coloring the names by apr -2 epoch which are
enclosed in a directory explicitly named 'apr-2/'. And absolutely absurd to
have two different aliases, period, which would then conflict with their -1
brethren. This needs to be reverted and solved as apr/apr_foo-2.so or as
apr-2/apr_foo.so.
Now for the real fun, with the exception of the borked -lssl/-crypto,
almost everything has successfully been isolated to their respective
sub-components. I'm sure some of you would be interested, this is a
shortlist of some autodetected components on our build on a modern Fedora;
[wrowe@hub apr-2]$ for f in *-2.so; do echo "$f dependencies;"; ldd $f; done
apr_crypto_openssl-2.so dependencies;
linux-vdso.so.1 (0x00007ffd60359000)
libssl.so.1.1 => /opt/openssl111/lib/libssl.so.1.1 (0x00007f95c75eb000)
libcrypto.so.1.1 => /opt/openssl111/lib/libcrypto.so.1.1
(0x00007f95c7301000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f95c727a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f95c70b4000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f95c70ae000)
/lib64/ld-linux-x86-64.so.2 (0x00007f95c7688000)
apr_dbd_mysql-2.so dependencies;
linux-vdso.so.1 (0x00007ffdd8dfc000)
libmariadb.so.3 => /lib64/libmariadb.so.3 (0x00007f914df66000)
libz.so.1 => /lib64/libz.so.1 (0x00007f914df4c000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f914df46000)
libm.so.6 => /lib64/libm.so.6 (0x00007f914ddc2000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f914dda0000)
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f914dd0a000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f914da29000)
libc.so.6 => /lib64/libc.so.6 (0x00007f914d863000)
/lib64/ld-linux-x86-64.so.2 (0x00007f914e029000)
apr_dbd_odbc-2.so dependencies;
linux-vdso.so.1 (0x00007ffe29883000)
libodbc.so.2 => /lib64/libodbc.so.2 (0x00007f73ec2a1000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f73ec27f000)
libc.so.6 => /lib64/libc.so.6 (0x00007f73ec0b9000)
libltdl.so.7 => /lib64/libltdl.so.7 (0x00007f73ec0ad000)
/lib64/ld-linux-x86-64.so.2 (0x00007f73ec385000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f73ec0a7000)
apr_dbd_pgsql-2.so dependencies;
linux-vdso.so.1 (0x00007fffcf8f5000)
libpq.so.5 => /lib64/libpq.so.5 (0x00007fe0f9cb3000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe0f9c91000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe0f9acb000)
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fe0f9a35000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fe0f9756000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fe0f9704000)
libldap_r-2.4.so.2 => /lib64/libldap_r-2.4.so.2 (0x00007fe0f96a9000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe0f9d6e000)
libz.so.1 => /lib64/libz.so.1 (0x00007fe0f968f000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fe0f9689000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fe0f9598000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fe0f957a000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fe0f9573000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fe0f955f000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fe0f9559000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fe0f953f000)
liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007fe0f952d000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007fe0f950e000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fe0f94df000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fe0f94a3000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fe0f9414000)
apr_dbd_sqlite3-2.so dependencies;
linux-vdso.so.1 (0x00007fff70fb9000)
libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00007fc7813ef000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc7813cd000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc781207000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc781083000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc78107d000)
libz.so.1 => /lib64/libz.so.1 (0x00007fc781063000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc781572000)
apr_dbm_db-2.so dependencies;
linux-vdso.so.1 (0x00007ffe5c298000)
libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f0a94855000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0a94833000)
libc.so.6 => /lib64/libc.so.6 (0x00007f0a9466d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0a94a85000)
apr_dbm_gdbm-2.so dependencies;
linux-vdso.so.1 (0x00007ffef6263000)
libgdbm.so.6 => /lib64/libgdbm.so.6 (0x00007f82cf46a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f82cf448000)
libc.so.6 => /lib64/libc.so.6 (0x00007f82cf282000)
/lib64/ld-linux-x86-64.so.2 (0x00007f82cf4e7000)
apr_dbm_ndbm-2.so dependencies;
linux-vdso.so.1 (0x00007ffed5d3a000)
libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f7a7f41b000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7a7f3f9000)
libc.so.6 => /lib64/libc.so.6 (0x00007f7a7f233000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7a7f64b000)
Re: The case for apr-util-2.0
Posted by Graham Leggett <mi...@sharp.fm>.
On 06 Jun 2019, at 10:38, Branko Čibej <br...@apache.org> wrote:
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 18.04.2 LTS
> Release: 18.04
> Codename: bionic
> $ apt-cache search aprutil
> libaprutil1 - Apache Portable Runtime Utility Library
> libaprutil1-dbd-sqlite3 - Apache Portable Runtime Utility Library - SQLite3 Driver
> libaprutil1-dbg - Apache Portable Runtime Utility Library - Debugging Symbols
> libaprutil1-dev - Apache Portable Runtime Utility Library - Development Headers
> libaprutil1-ldap - Apache Portable Runtime Utility Library - LDAP Driver
> libaprutil1-dbd-mysql - Apache Portable Runtime Utility Library - MySQL Driver
> libaprutil1-dbd-odbc - Apache Portable Runtime Utility Library - ODBC Driver
> libaprutil1-dbd-pgsql - Apache Portable Runtime Utility Library - PostgreSQL Driver
> $ apt-cache show libaprutil1
> Package: libaprutil1
> [...]
> Depends: libapr1 (>= 1.6.2), libc6 (>= 2.25), libdb5.3, libexpat1 (>= 2.0.1), libgdbm5 (>= 1.14), libssl1.1 (>= 1.1.0)
> […]
That looks like a packaging bug. This is on CentOS7:
[minfrin@chandler ~]$ ldd /usr/lib64/libapr-1.so.0.6.3
linux-vdso.so.1 => (0x00007ffee65c1000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f8d24138000)
librt.so.1 => /lib64/librt.so.1 (0x00007f8d23f30000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f8d23cf9000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8d23add000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f8d238d9000)
libc.so.6 => /lib64/libc.so.6 (0x00007f8d2350c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8d24578000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f8d23309000)
[minfrin@chandler ~]$ ldd /usr/lib64/libaprutil-1.so.0
linux-vdso.so.1 => (0x00007ffd83171000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f2813501000)
libapr-1.so.0 => /lib64/libapr-1.so.0 (0x00007f28132c6000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f28130c1000)
librt.so.1 => /lib64/librt.so.1 (0x00007f2812eb9000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f2812c82000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2812a66000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f2812862000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2812495000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2813962000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f2812292000)
> I specifically object to libexpat, libssl, libdb and libgdm being on
> this dependency list ... the latter two are just bloat, but the former
> two create all sorts of problems for any project that happens to use
> either of them directly.
+1.
Looking at the archeology, this problem was identified years ago, and each successive addition has been properly modularised. What was needed was to go back and modularise the earliest additions.
Regards,
Graham
—
Re: The case for apr-util-2.0
Posted by Branko Čibej <br...@apache.org>.
On 06.06.2019 09:29, Nick Kew wrote:
>> 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.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic
$ apt-cache search aprutil
libaprutil1 - Apache Portable Runtime Utility Library
libaprutil1-dbd-sqlite3 - Apache Portable Runtime Utility Library - SQLite3 Driver
libaprutil1-dbg - Apache Portable Runtime Utility Library - Debugging Symbols
libaprutil1-dev - Apache Portable Runtime Utility Library - Development Headers
libaprutil1-ldap - Apache Portable Runtime Utility Library - LDAP Driver
libaprutil1-dbd-mysql - Apache Portable Runtime Utility Library - MySQL Driver
libaprutil1-dbd-odbc - Apache Portable Runtime Utility Library - ODBC Driver
libaprutil1-dbd-pgsql - Apache Portable Runtime Utility Library - PostgreSQL Driver
$ apt-cache show libaprutil1
Package: libaprutil1
[...]
Depends: libapr1 (>= 1.6.2), libc6 (>= 2.25), libdb5.3, libexpat1 (>= 2.0.1), libgdbm5 (>= 1.14), libssl1.1 (>= 1.1.0)
[...]
I specifically object to libexpat, libssl, libdb and libgdm being on
this dependency list ... the latter two are just bloat, but the former
two create all sorts of problems for any project that happens to use
either of them directly.
So yes, it would be nice to abstract such dependencies out of the core
APR 2.0 as that might (maybe, possibly) convince downstream packagers to
think a bit more carefully about packaging optional dependencies.
> Having said that, reversing the split from where we are now could
> just be more confusion. Ho, hum.
What, confusion for everyone who uses APR 2.0 today? I feel a distinct
lack of interest. :)
[...]
> I think you're arguing for fully-baked apr modules, yesno?
I'm not sure what you mean by "fully baked." IMO it would be good enough
if dependencies such as dbd and crypto (and possibly xlate) could be
loaded at APR initialisation time but never unloaded.
-- Brane
Re: The case for apr-util-2.0
Posted by Nick Kew <ni...@apache.org>.
> 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
Re: The case for apr-util-2.0
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jun 6, 2019, at 5:04 AM, Graham Leggett <mi...@sharp.fm> wrote:
>
> On 06 Jun 2019, at 07:07, Mladen Turk <mt...@apache.org> wrote:
>
>> 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.
>
+1 as well.
Re: The case for apr-util-2.0
Posted by Graham Leggett <mi...@sharp.fm>.
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
—