Re: Disconnecting -lldap from utilizing apr-util

[Graham Leggett]

William A. Rowe, Jr. wrote:

What is interesting is that a patched apr-1.3.x remains binary compatible.
Simply ./configuring --enable-dbd-dso (really should be --enable-dsos) in
combination with --with-ldap will toggle the behavior.

Am I correct in understanding that this brings the LDAP binding in line 
with the exact same behaviour as the DBD bindings?

A definitely +1 to behaviour that is consistent between DBD and LDAP.

But this is not far enough, and only phase 1 of a patch.  The complete
patch should abstract the rest of the ldap provider such that they do not
need to bind to -lldap in the first place.  If this is not the goal, I'd
argue that this ldap binding really wasn't appropriate in the first place.

To answer the question as to why the LDAP bindings are as they are:

The LDAP C API is a standard. All the toolkits out there, have the exact 
same bindings for all the functions in the standard. The problem was, 
the standard completely omitted SSL/TLS.

Every toolkit out there invented their own weird way of configuring 
SSL/TLS. Every toolkit out there has it's own weird library 
requirements, different per platform. And by every toolkit I mean 
OpenLDAP, Netware, Mozilla, Microsoft, Solaris, and some others whose 
names I don't remember, on Windows, Solaris, Linux, etc.

The first consumer of the LDAP binaries, httpd, didn't want to care what 
heinous list of hoops you had to jump through to make LDAP magically 
become available on your chosen platform. This fell to the "P" in APR. 
APR removes a *serious* headache from LDAP users.

One thing httpd *didn't* need was APR wrappers for every single LDAP 
function in the LDAP C API standard, simply because it was a standard. 
As a result, only the incompatible stuff is implemented in the apr 
namespace. The whole LDAP library wasn't wrapped, simply because it 
wasn't necessary at the time.

Wrapping the LDAP library however does make things cleaner, and does 
empower us to create standard behaviour should a future LDAP library 
come along and act funny. So if you want to wrap all the LDAP functions 
for v2.0, I think it is a good idea. It also makes LDAP work like DBD, 
and as I said above, consistent is good.

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature