apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Dependencies and Modularity in APR
Date Sat, 11 Dec 2004 20:10:30 GMT

The apr_dbd code I posted a few days ago is in 'classic' APR shape.
Like, for example, apr_dbm, it allows different backends to be
configured or omitted, but only at build time.

This seems to me less than ideal even for DBM.   In the case of DBD,
the backends are major applications in themselves, and hardwiring them
at build time seems to be seriously suboptimal.  So I've re-hacked
the DBD code to load them dynamically when APR_DSO is enabled.
This also means a user can introduce new drivers at any time,
for example when they have installed a new database or updated a
version, without touching the installed APR.  Each driver now compiles
as a separate .so, which should be linked to the appropriate client lib.
It's now loaded as a DSO on first reference.

I've also dealt with a number of points raised in discussion here
and on IRC in response to my previous post.  That means some modest
updates to the API.

I don't have APR karma, so I'm spared having to infer whether I have
a mandate to commit them.  But I'm attaching the updates.  I'd like
to reach a decision soon, so it can either go into APR and benefit
from our collective efforts, or revert to my control without reference
to anyone else.

The attached is broadly similar to its predecessor: works for me,
but not recommended for operational use.  The PostgreSQL driver has
trouble with the Prepared Query test: this has got me baffled, and
any help is appreciated - along with general comments and tests,
of course.

-- 
Nick Kew
Mime
View raw message