[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP API questions
If I was going to write a new application today, I'd write to the
latest IETF LDAPext C API specification and than #ifdef as needed
to support implementation differences for SDK which gain me
significant platform coverage. I wouldn't bother supporting
APIs which are soon to be deprecated.... like RFC1823, U-Mich,
OpenLDAP 1.x APIs, Netscape SDK 3.0? There is enough variance
in the "experimental" LDAPext C API implementations to deal with...
I would hesitate before mixing in older APIs.
Most LDAP vendors (Netscape, Innosoft, others) are supporting
LDAPext C API implementations. Our implementation is in development.
At 02:57 PM 3/8/00 -0500, Thomas J Pinkl wrote:
>My questions:
>
> 1. How do you distinguish between the various LDAP SDK's,
> programmatically? Currently, if the LDAP_OPT_SIZELIMIT symbol
> is defined, I assume that I'm using Netscape's SDK. I selected
> that symbol somewhat arbitrarily.
See: http://www.openldap.org/lists/openldap-devel/199901/msg00097.html
[It details how to detect LDAPext C API implementations
vs Netscape vs OpenLDAP/U-Mich. See also the LDAPext draft
for info on how to detect vendor version info.]
> Is there a better way to do this?
Write autoconf macros to detect functions specific to SDK being
used.
> 2. What differences exist in the LDAP API supplied by the various
> LDAP SDK's? Some differences that I know of are:
The Howes/Smith notes some differences between U-Mich and Netscape SDK.
Since OpenLDAP is U-Mich (~RFC1823), all of these differences should
apply.
Seems like you listed the most significant differences. Note, however,
there are many subtle differences which would take significant time
to list.
> a. Netscape wants to treat the LDAP session handle (eg. LDAP *ld)
> as an opaque structure, and therefore supplies functions to get
> at its internals. This affects how the programmer gets at
> ld_errno, for example.
Various other structures are opaque as well.
> b. OpenLDAP returns a char pointer from ldap_first_attribute() and
> ldap_next_attribute(), to a static buffer. Therefore, you must
> not free() the returned pointer. The Netscape documentation
> tells you to call ldap_memfree() on the pointer returned by
> ldap_first_attribute() and ldap_next_attribute(). Note that
> OpenLDAP has no ldap_memfree() function.
>
> c. OpenLDAP documents the ber_free() function, while Netscape's
> documentation talks about ldap_ber_free(). However, Netscape's
> example programs use ber_free() and that function *is* in their
> library. The book I cited above also uses ber_free().
>
> d. The Netscape SDK requires you to link in a threads library (eg.
> -lpthread). I have the Netscape SDK with SSL support. I have not
> used the one without SSL, so I don't know if it is any different.
> This caused a problem for my application, which is not threaded.
> My application would become wedged in __sigsuspend() after having
> several of its clients connect and/or disconnect simultaneously.
> Not being familiar with debugging threaded programs, my solution
> was to switch to the OpenLDAP SDK. This "solved" the problem.
>
> e. When using the OpenLDAP SDK, you will not normally call ber_free()
> following the classic for(...) loop to fetch an entry's attributes.
> Doing so will eventually cause a SIGSEGV (ie. a segmentation
> violation). This is because OpenLDAP's ldap_next_attribute() has
> already freed the BerElement when it returns NULL, signaling the
> end of the entry's attributes. With the Netscape SDK, you *do*
> need to call ber_free() (or ldap_ber_free(); see above).
>
> What other differences exist between LDAP SDK's?
Likely many.
>I would appreciate hearing from anyone who has used more than one LDAP
>SDK. Thanks in advance.
Sendmail 8.10 supports, I believe, both Netscape and U-Mich/OpenLDAP 1.x SDKs.
You might check out how they managed the differences.