On Aug 18, 2010, at 4:34 PM, Howard Chu wrote:
my purpose in directing the conversation here is to discuss why.
It's not clear to me that this old draft is still viable or desirable. As we've
talked about many times before, the C API is a huge mess and we need to toss the current
one out and go back to the drawing board, preferably to come up with a new API that
doesn't meld operational behavior (e.g. referral chasing) with the low level protocol
implementation, and one that is largely free-threaded.
At one time, I must have through the draft's suggested changes to the LDAPext-proposed
U-Mich-based LDAP C API where a good idea. Lots of time has passed since that time.
Taking a step back, as I'ved noted many times, I would support introduction of a new
LDAP C API which focused on encoding/decoding of LDAP constructions and not I/O management
and not higher level handling such as managing distributed contexts. Such a API could
and, I certainly would argue, should be be thread-free. Given this, one could use this to
offer higher level APIs. I would prefer to, in the long run, dump the U-Mich APIs as I
think it's a dead-end (though I think that dead-end might be many, many miles down the
I don't object to continued work on the OpenLDAP LDAP C API. Bug fixes (Ando
commented that some of the Doug's changes can be viewed as Bug fixes) are certainly
I also don't object to introduction of additional capability so long as that
introduction doesn't "break" applications specifically designed to use prior
(within reason) versions of the OpenLDAP LDAP C API upon upgrade.
I am generally opposed to adding additional APIs just to additional APIs which offer zero
new capability and am generally opposed to adding new deprecated APIs. Also, I also
don't generally accept the argument that introduction of interfaces found in other
LDAP C APIs 'eases' porting of LDAP applications. But let's look at
Today there are multiple flavors of the ldap_get_lderrno() API. I found two different
non-OpenLDAP LDAP C APIs to include an ldap_get_lderrno() interface with the signature:
int ldap_get_lderrno(LDAP *ld, char **dn, char **errmsg);
but with incompatible semantics. One required the caller to free the strings returned in
dn and errmsg. One didn't, as the dn and errmsg were simply set to point to the
strings held in the LDAP structure.
The expected problems introduced are differ depending on whether OpenLDAP
ldap_get_lderrno(), it should be clear that problems are introduced. Simply put, despite
the introduction of ldap_get_lderrno(), application developers need to be careful in
porting to ensure that OpenLDAP offers compatible semantics to what they offer. And that
likely requires reading, at a minimum, the documentation.
I rather developers simply port their code to use ldap_get_option(3) interface here, which
because of inclusion in the LDAPEXT LDAP C API drafts (even through expired), are far more
consistently implemented than routines such as ldap_get_lderrno().
I also oppose adding ldap_get_lderror().
Beyond this, I haven't reviewed the patch in detail. I think I'll leave that more
current and more active in the development of OpenLDAP Software.