apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: [VOTE] LDAP in APR 2.x?
Date Tue, 24 Mar 2009 11:53:11 GMT
On Tue, Mar 24, 2009 at 12:33 PM, Graham Leggett <minfrin@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.

Mime
View raw message