Graham Leggett wrote:
The APR LDAP code goes to significant lengths to support a single unified API across something like *seven* different LDAP implementations across a wide set of platforms.
yes...
Despite the C API being a standard, support for extensions like SSL and LDAP options have resulted in 7 completely different implementations that work completely differently from the next. Coming up with a sensible common API was no mean feat.
I can strongly disagree by looking at how many feature-tests and strange macro comparisons are used in util_ldap or mod_authnz_ldap of httpd. Clearly we've failed - it isn't anywhere near ready for run-time alteration of a provider, eh?
The point behind APR is to solve these problems. Patches welcome.
++1; the point isn't to ponder dropping one for it's bugs, but to set out to add functionality to apr-util-1.3 to break our compile-time dependencies on the consumer of apr-util, and in apr-util-2.0 to deprecate bogusness.
