On Mon, Oct 31, 2016 at 10:49 AM, Graham Leggett <minf...@sharp.fm> wrote:
> On 31 Oct 2016, at 5:05 PM, Jim Jagielski <j...@jagunet.com> wrote: > > > Moving to APR: > > > > Query: Think it would be worth my time to work on a Redis > > implementation for APR-util? I am working on a minimal Redis > > lib, related to work, which is basically a soft reboot of Credis > > from GoogleCode, which could serve as the core functionality, which is > > what got me thinking about it. > > +1. > Agreed, if this is done as yet another loadable provider... To the point about memcache not being a loadable component, keep in mind it is a self-contained, lightweight component. It -could- be abstracted into a loadable module, but with no library dependencies a switchable framework was never a priority to a developer. As long as the ABI to apr_memcache is maintained, it could become loadable with a 1.6 revision bump and the broader API touch any of these stores. With a modular interface, then the question of redis vs credis vs other implementations is a no-brainer, we can support multiple implementations. > You have a point, there is nothing stopping us creating an > apr-util-cache-redis package with a lifecycle of it’s own. > What's the win on this? I think we discussed this at length in the APR 0.9 graduation to 1.0 and decided monolithic had plenty of advantages. It was further simplified with 2.0. It can certainly be revisited but this served us well for 15 years and gave distributors the ability to break out the many lib/apr-util-1 subcomponents based on library inter-dependencies. Right now in apr-2, our *hard* lib dependencies look like; $ ldd .libs/libapr-2.so linux-vdso.so.1 (0x00007ffde8fa1000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f25e7e40000) librt.so.1 => /lib64/librt.so.1 (0x00007f25e7c38000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f25e7a01000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f25e77e5000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f25e75e1000) libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f25e7276000) libc.so.6 => /lib64/libc.so.6 (0x00007f25e6eb4000) /lib64/ld-linux-x86-64.so.2 (0x000055ca56625000) libfreebl3.so => /lib64/libfreebl3.so (0x00007f25e6cb1000) libz.so.1 => /lib64/libz.so.1 (0x00007f25e6a9a000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f25e6874000) libm.so.6 => /lib64/libm.so.6 (0x00007f25e656b000) (Note that several dependencies are between Fedora 25 components in my example above, e.g. libfreebl3.so is not consumed by 'apr' - I'm suspecting that libxml2 drew in several subdependencies.) So far we haven't made libxml2 / libexpat a truly loadable selection. But we've succeeded in keeping all of these components and their library dependencies out of the process map for all apr-consuming apps which don't invoke these API's... 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 APR-util 1.6.x is even sleeker, using expat rather than libxml2... $ ldd .libs/libaprutil-1.so linux-vdso.so.1 (0x00007ffc02fcd000) libexpat.so.1 => /opt/bleed/lib/libexpat.so.1 (0x00007f4c9ab37000) libapr-1.so.0 => /opt/apr16-ossl102/lib/libapr-1.so.0 (0x00007f4c9a8ff000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f4c9a6a9000) librt.so.1 => /lib64/librt.so.1 (0x00007f4c9a4a1000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f4c9a26a000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4c9a04e000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f4c99e4a000) libc.so.6 => /lib64/libc.so.6 (0x00007f4c99a87000) /lib64/ld-linux-x86-64.so.2 (0x000055a9a1c31000) libfreebl3.so => /lib64/libfreebl3.so (0x00007f4c99884000) So my only objection would be adding any hard dependency to any redis provider. If it's module, and apr_memcache can map into the same framework, we can keep extending this for a very long time. > There is an extension to apr_crypto on apr-util v1.6 that I’d like to get > out the door, redis for apr_socache can go out at the same time. > apr is probably worth refreshing at the same time, for some bug fixes and new 1.6 APIs. You raised a good point, we don't release often because the code is quite stable. If we are enhancing APR, we should be moving ahead with more frequent releases. The actual work/development/progress should drive releases, not some artificial calendar for very few changes. The feature sounds like a win!
