apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: 1.0.0 RC5
Date Tue, 03 Aug 2004 14:19:38 GMT
At 06:08 AM 8/3/2004, Graham Leggett wrote:
>William A. Rowe, Jr. wrote:
>> Right now it does little.  Graham and I agree on the right solution,
>> to abstract out the logic to do SSL connections in a portable way.
>> There will be no need for the 'application developer' to know which
>> toolkit they are using.  We will make that transparent.
>This has already been done, and is already checked into apr_util.

Very cool!  I am traveling non-stop so haven't dug into the code, and
probably can't till Tuesday.  That 40% of the 80%...

>>Least action is fork 1.1, cvs rm the offensive files, and change about
>>10 lines of the makefiles and rip out the ldap detection.  Pretty trivial.
>That's overkill.
>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 :)

>>Deprecating means we support this junk till 2.0 releases.
>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(...);
    [all the code]

>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?


View raw message