Re: Disconnected ldap, abstracted dbd.

[William A. Rowe, Jr.]

William A. Rowe, Jr. wrote:

Eric Covener wrote:

+1 on wrapping it all in 2.0, but I don't think the versioning
restrictions allow apr-util to stop linking against LDAP in 1.3 -- for
example applications that load ldap symbols privately  ("not at all"
shouldn't be an issue because they can't do anything useful with the
apr-util LDAP API in that case).

Be aware that there is a one line change to most applications who want
apr-1.3.x to provide that binding for them (so they can use the symbols
privately).  Simply, this would just no longer be the default.  I think
that's a healthy thing since this affects < 10% of applications that
consume apr-util, and of the others, they would be better off linking
ldap only for specific components, e.g. mod_ldap/mod_authnz_ldap.

http://people.apache.org/~wrowe/ldap/apr-util-1.x-dso.patch has been
committed and is ready for review.  If I hear no objection I'll roll
on in the morning to 1.3.0 for apr and apr-util.  There should be no
API change going into applying this concept for dbm, iconv or xml
so those are not showstoppers.

The dbd and ldap are both abstracted to use the apu_dso_load.  There is
an apu_dso_init but it will be implicitly called for apr 1.x; in apr 2.x
we can dictate that the users must explicitly invoke a general apr-util
initializer.  The loaded dso's lifetime is the process lifetime.

Netware has a real problem, it's apr_pool_parent_get stops short of the
root pool.  Two consumers with different pools will not share the loaded
resources and can cause the 2nd consumer to segv when the 1st consumer
frees it's highest level pool.  Bad mojo, nothing I can do about it since
I have no clue why this exception was made on Netware.

The changes permit us to run make test without installing the loadable
dso dbd and ldap providers, the make file is hacked to include these in
the shared lib path.

Note that we keep two hashes, new is private dsos hash of modules by their
module name.  While dbd is refactored to use the apu_dso schema, it's still
most efficient to continue to maintain a hash by the driver's shortname.

Please, review.  Thanks.

Bill