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(...);
#else
[all the code]
#endif
>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?
Bill
