You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2004/08/02 02:51:32 UTC
Re: apr-util/ldap/ - sink or really swim to 1.0 release?
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