apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: 1.0.0 RC5
Date Tue, 03 Aug 2004 19:07:47 GMT
William A. Rowe, Jr. wrote:

>>The two most important bits of the LDAP support are ./configure magic to find the
right toolkit, and the newly overhauled apr_ldap_init.c, which replaces the LDAP SDK's inconsistent
ldap_init() function. These should work fine.

> No - the most important bit is to start hiding the details in apu_private.h
> and quit publicizing the sdk versions, define mapping wrappers, etc.
> Once everything that aprutil-1 elects to do is hidden inside aprutil-1.so,
> and the interface is always the same (no matter which linkage), then
> we have 1. defined binary compatibility, and 2. stuck to it :)

I was referring to the most important bit of the functionality - you're 
referring to the most serious bit of the fooness :)

I think the code with the most fooness is also the code with the least 
impact - so chopping it shouldn't cause too many problems, and certainly 
not problems that can't be fixed in v1.0.1.

>>Then cvs rm apr_ldap_url.c, which seems to be the main issue. We can fix it and put
it back in the next release.

> Actually, isn't that the most trivial to fix?  
> #if HAVE_ldap_parse_url
>     return ldap_parse_url(...);
> #else
>     [all the code]
> #endif

What it does now is this:

   [all the code]

Inside the code it then defines apr_ldap_is_ldap_url() - but only if 
APR_HAS_LDAP_URL_PARSE is false, which makes no sense.

This is definitely bogus - let me see if I can fix it.

>>What issues are there with apr_ldap_compat.c? This code is very short, and any issues
are probably easily fixed.

> iirc this is a bunch of macros.  Any code linked against one flavor
> of aprutil-1.so can't be expected to load under another.  This is
> problematic, no?

Looking at this further, the apr_ldap_compat is a "fill in" function for 
LDAP v2 servers. It defines ldap_search_ext_s() and ldap_memfree() for 
LDAP v2 servers, where these functions were missing from the C SDK.

In the header file, the macro defines handling a difference between the 
v2 LDAP SDK and the v3 one.

Therefore I ask: How important is LDAP v2? Can we just chop LDAP v2 
support for APR 1.0 - we get rid of the macros and the spare functions.

We can do LDAP v2.0 support (as opposed to v3.0 support we do by 
default) in the proper APR way later.


View raw message