On Monday 13 August 2001 13:12, Graham Leggett wrote: > Ryan Bloom wrote: > > There are already multiple LDAP libraries, what are we trying to solve by > > putting an abstraction layer into APR? Are we sure that the problem > > needs to be solved, or are we doing work just to do work? > > There are multiple LDAP libraries - which is exactly why the LDAP > library was abstracted. There is the "standard" way of doing things, > then there is the "netscape" way of doing things, which has just changed > again to the "iplanet" way of doing things - then throw in the two > different ways of doing SSL/TLS (netscape|standard) - linking against an > LDAP library is a real pain in the ass.
Then this is the only thing that should be in apr_ldap. If we are trying to create a wrapper library to abstract out differences in all of the other LDAP libraries, then I _might_ be able to get behind that. > Then there is the idea that we don't want to > connect/bind/query/unbind/disconnect many times per connection (which > happens if auth_ldap and keepalives are used together) or if auth_ldap > and the LDAP-proxy backend are used together - thus the caching and > connection reuse abstraction layer to do this. None of that stuff belongs in apr-util. This has nothing to do with portability, this has to do with attaching LDAP to a web server. If this is something that we want to provide as a standard part of Apache, not sure we do (haven't thought about it much), then it should be a part of the module that attaches the two together, not a part of the abstraction library. > At all times the core LDAP library is available should the application > want to use it. The LDAP layer is an addition to rather than an > interface to LDAP. The code for the layer was sourced from an existing > Apache module - auth_ldap, which has been around for quite a while and > is stable. If these routines are not meant to be an abstraction layer for all LDAP libraries, then they do not belong in APR or APR-util. Again, I really want to understand why we need this to be a part of APR-util. Ryan ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
