On Tue, Mar 24, 2009 at 12:33 PM, Graham Leggett <minf...@sharp.fm> wrote:
> Jeff Trawick wrote: > > any counter-knowledge/opinions on the following? >> >> assert(only httpd uses apr LDAP) >> > > Can you cite references to show this is so? I would be very hard pressed to > assert that functionality that has been available in APR for many years > would have just one single user. That is not a standard of proof we use for any feature when moving to the next major version. We could never remove anything if we assumed that somebody, somewhere was relying on the feature AND it was imperative that APR continue to support such features. (That's different than not considering the problems we'd create for apps that we know use a feature; we can't be paralyzed by what we don't know.) > > > assert(new open source software assumes OpenLDAP) >> > > Does OpenLDAP run on Windows? (I would imagine not, considering Windows has > its own native LDAP stack). sure; one scenario where I've heard OpenLDAP+WIndows mentioned multiple times is with PHP, which intersects with APR > Does OpenLDAP support Mozilla NSS? (strategic direction of the Fedora > distro). > dunno > > > assert(LDAP support in apr won't increase adoption of apr) >> > > Not sure how this is relevant? relevant to a consideration of "compelling value" of APR; related to the question of what apps use LDAP in APR; to what extent are the problems we solve in APR providing value > > > assert(LDAP support in apr could make us a party to ugly combinations of >> LDAP different toolkits in the same address space, which isn't a problem we >> have addressed in the past) >> > > There is no way you could ever have two LDAP toolkits in the same address > space anyway. sure you can; it just doesn't work as expected ;) (IOW, this is an actual problem; we've discussed a bit of it on the list (openldap w/ or w/o "_r", though the problem is just as often openldap vs fooldap) > > > The LDAP C API is a (draft) standard: understood > A problem we do have however, is that APR can currently only compile > against one single LDAP toolkit at a time. This goes against the pattern of > apr_dbd, where end users can choose from one of many providers. > I don't see any problem with completely wrapping the LDAP API. It will > solve the single-LDAP-toolkit problem above. > sure; those would go hand in hand (full API, ability to plug in a different shared object to utilize a different LDAP (or _r) > > I feel like voting for "Fix the LDAP interface..." but I don't see anybody >> caring but httpd, and the widespread use of Linux/OpenLDAP for developing >> the apps in our space has made this an unstrategic problem to solve. >> > > Since when does the widespread use of a single platform (Linux/OpenLDAP) > preclude the support for other platforms (Windows/Active Directory, > Fedora/NSS, etc)? These are all criteria *I* consider when considering the value of LDAP in APR, and as I stated I'm interested in better understanding of the details. Everyone will have to pick their own criteria, and raise the particular points of interest to them.
