apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: 1.0.0 RC5
Date Tue, 03 Aug 2004 19:43:52 GMT
>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.

+1,  V3 has been around for a while.  Let's support V2 later if needed.
 My bet is that it won't be needed.

Brad


Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> Graham Leggett <minfrin@sharp.fm> Tuesday, August 03, 2004 1:07:47
PM >>>
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:

#if !APR_HAS_LDAP_URL_PARSE
   [all the code]
#endif

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.

Regards,
Graham
--


Mime
View raw message