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 road).
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 not objectionable.
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 ldap_get_lderrno() specifically.
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.
-- Kurt