Jeff Trawick wrote:
any counter-knowledge/opinions on the following?assert(only httpd uses apr LDAP)
Can you cite references to show this is so? I would be very hard pressed to assert that functionality that has been available in APR for many years would have just one single user.
assert(new open source software assumes OpenLDAP)
Does OpenLDAP run on Windows? (I would imagine not, considering Windows has its own native LDAP stack). Does OpenLDAP support Mozilla NSS? (strategic direction of the Fedora distro).
assert(LDAP support in apr won't increase adoption of apr)
Not sure how this is relevant?
assert(LDAP support in apr could make us a party to ugly combinations of LDAP different toolkits in the same address space, which isn't a problem we have addressed in the past)
There is no way you could ever have two LDAP toolkits in the same address space anyway.
The LDAP C API is a (draft) standard: http://www.ietf.org/proceedings/01mar/I-D/ldapext-ldap-c-api-05.txtAs a result, all LDAP libraries export the same symbols, and therefore cannot coexist in the same address space by definition.
If the initiative to change the LDAP API is an attempt to load two LDAP libraries into the server at once, then people need to familiarise themselves with the LDAP C API first, before trying to push for major surgery to solve a problem we don't have.
A problem we do have however, is that APR can currently only compile against one single LDAP toolkit at a time. This goes against the pattern of apr_dbd, where end users can choose from one of many providers.
I don't see any problem with completely wrapping the LDAP API. It will solve the single-LDAP-toolkit problem above.
I feel like voting for "Fix the LDAP interface..." but I don't see anybody caring but httpd, and the widespread use of Linux/OpenLDAP for developing the apps in our space has made this an unstrategic problem to solve.
Since when does the widespread use of a single platform (Linux/OpenLDAP) preclude the support for other platforms (Windows/Active Directory, Fedora/NSS, etc)?
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
