On 26 Jun 2011, at 3:16 PM, Stefan Fritsch wrote:
Nobody said that this would be magically fixed by moving the stuff to HTTPD. But it means that the apr libraries are no longer involved in the mess, which is already very helpful for distributions like Debian. With the apr 1.x situation, an ABI break (soname change) in openldap means we have to jump through hoops to prevent crashes when httpd uses one version of openldap and apr uses a different version.
This is fixed by calling the ldap_get_option() function described in section 9.2 of http://www-archive.mozilla.org/directory/ietf-docs/draft-ietf-ldapext-ldap-c-api-05.txt . There is no need to move the code to support this, this can be supported today by adding the appropriate sanity check on init and failing as appropriate.
I think you misread that comment. The patch attached to the PR makes it work with Solaris LDAP but breaks with OpenLDAP, therefore it is not acceptable.
Looking at the patch in more detail, the patch makes indiscriminate attempts to change the behaviour of all the platforms at the same time, instead of targeting the Solaris platform only. OpenLDAP will break by definition in this case, as will other platforms.
What the patch needs to do is properly isolate the functions being used on Solaris (ldapssl_init()? ldap_sslint()? something else?), and modify them only, using #ifdef where appropriate.
But this highlights another problem with how we deal ldap: There is no way a developer can test changes on all or even on a significant subset of the supported toolkits. This makes it very hard to do any changes at all. Ideally we would only support toolkits/plattforms that are available at the ASF for testing.
The apr_dbd and apr_crypto APIs already demonstrate how to solve this problem, and the plans for apr_ldap in v2.0 are to implement an API that follows the same pattern.
The apr_dbd and apr_crypto APIs have had various shortcomings that need to be fixed in APR v2.0, and this has held up work on apr_ldap.
Regards, Graham --
