At 12:26 PM 7/30/2004, Graham Leggett wrote:
>William A. Rowe, Jr. wrote:
>
>>4. our APR_HAS_XXX_LDAPSDK macros are entirely bogus, still,
>>   on unix.
>
>Explain? (so I can fix).

Here's my philosophy.  First, we don't set up the HAS_BAR_LDAPSDK 0
values after setting the HAS_FOO_LDAPSDK 1 value.  So this is a bug.

But everything that we do relative to 'which toolkit is this?' should be behind
the apu_private.h section, can use the classic HAVE_FOO_LDAP style
macros, and shouldn't be shared.

If we are describing ldap in terms of 'which toolkit?' then we didn't go
to enough effort in apr-util/ldap to make this even worthwhile.  My 2c.

>>5. we *bogusly* define ldap_memfree and ldap_search_ext_s in the
>>   *ldap*'s namespace.  This is absolutely incorrect, and will immediately
>>   cause any ldap-based code to fail once the ldap library is upgraded
>>   (symbolic duplicates.)
>
>I plan to change all the apr defined ldap functions to be apr_ldap - will this fix this?

Ack :)  But I would ask, please, wrap behind functions not macros.
In that way, changing the aprutil-1.so file can immediately result in
using an alternate ldap provider.

Thanks for getting excited about this - 'finishing' ldap apr support is good.
I simply asked because releasing the 'old ldap' support as 1.0 would have
dug us a deep hole, it would have been easier to release, sans ldap, then
reintroduce in 1.1.  But since you have the energy and motivation to just
get it right - kudos and my thanks.

Bill