I understand w.r.t. the depreciated and additional error functions.
They are not specifically required for anything we are doing, I saw
them as convenience APIs. I will remove them as part of my next
round code changes.
I also wasn't aware that there were multiple flavors of the same
API signature. I agree that adding another instance would only
work to confuse the situation even more.
Doug.
On 08/22/10 01:53 PM, Kurt Zeilenga wrote:
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
