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.
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.
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.
What issues are there with apr_ldap_compat.c? This code is very short, and any issues are probably easily fixed.
Regards, Graham --
