On 7/7/2011 1:44 PM, Nick Kew wrote: > > On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote: > >> [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk >> (binding mod_ldap to ldap libs) > > +1. But get it right: not a botch job just because there's > pressure to release. Should really have been alpha rather > than beta when this blew up, but too late to change that.
Yes, /someone/ should have acted on the decision of mid-2009 back in that year ;P Since it fell onto me, and I didn't want apr 2.0 to break our httpd 2.4 during its lifespan, well... at least the code came across complete, except for the APU_DSO logic which makes no sense (why would we dynamically link to ldap when the module is already bound to ldap?) As this code and config logic had existed for some time, I expected the entire move to be relatively less painful than it appears to be. Define 'botch job'; I understand that, right now, we are not happy with the placement of the AP_HAS_LDAP symbol, that we were not happy with the load order dependency of mod_ldap loading before mod_authnz_ldap (fixed by jorton, rjung and sf). Other than resolving where AP_HAS_LDAP should be declared, what are the other concerns? That wouldn't rise to my definition of a botch job. My understanding is that there is a veto on the addition of ap_ldap API's in win32 (which Graham's vote would appear to void). Is there a much more narrow veto present? I suspect we have one flag too many to indicate the presence of an LDAP provider and will remedy this in ap_config_auto.h/ap_config.hw|hnw.
