On 7/7/2011 12:14 PM, Jeff Trawick wrote: >> [ ] Move ap_ldap API's to yet another mod_ldaps[1] module >> (binding both mod_ldap and mod_ldaps to ldap libs) > > IIUC, the only benefit (and a great one) to yet another ldap shared > library (whether mod_foo or in apr) is if there is a complete > abstraction, such that only one shared library binds to libldap* and > that one shared library can be switched out to switch client libraries > and libldap* symbol use doesn't leak between different functional > areas. > > Is there some other possibility?
As things stand, if mod_ldap provides all of the fundamental interop, it would be the only module that needs to be swapped out, which is why I'm partial to option #. It looks like the only function invoked by mod_authnz_ldap in ldap libs themselves is ldap_add(). If that were abstracted, mod_authnz_ldap would have no bindings to the ldap impl. I don't care for option #3 unless mod_ldap entirely consumes the new module and does not, itself, need to be bound to the ldap provider. Another approach to #3 is to rename it to correspond to Graham's claim of its scope, and to call the ap_ldap functionality as mod_ldap.
