You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2009/03/24 11:26:36 UTC
[VOTE] LDAP in APR 2.x?
So, during the conversations we've had here in Amsterdam regarding
combining APR and APR-util (see post from Paul), one of the big
stumbling blocks has been our treatment of the LDAP interfaces via
APR-util.
The crux of the issue is that it is a 'leaky' abstraction - in that,
APR-util does not currently *fully* wrap the LDAP interfaces -
instead, it is viewed as augmenting the standard LDAP APIs with
treatment for LDAP-SSL, etc, etc. This middle ground doesn't really
suit the APR philiosophy - cf. DBD and DBM interfaces.
Therefore, the consensus of the folks here is that we should pursue
one of the following courses of action:
[ ] Fix the LDAP interface to be a complete/full LDAP abstraction
[ ] Remove the LDAP interfaces from APR
Thanks. -- justin
Re: [VOTE] LDAP in APR 2.x?
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Mar 24, 2009 at 11:26:36AM +0100, Justin Erenkrantz wrote:
> [ ] Fix the LDAP interface to be a complete/full LDAP abstraction
> [X] Remove the LDAP interfaces from APR
Folding this code into mod_ldap seems like the right thing to do.
Regards, Joe
Re: [VOTE] LDAP in APR 2.x?
Posted by Paul Querna <pa...@querna.org>.
On Tue, Mar 24, 2009 at 11:26 AM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> Therefore, the consensus of the folks here is that we should pursue
> one of the following courses of action:
>
> [ ] Fix the LDAP interface to be a complete/full LDAP abstraction
> [X] Remove the LDAP interfaces from APR
It belongs in httpd, if anywhere :)
Thanks,
Paul
Re: [VOTE] LDAP in APR 2.x?
Posted by Ruediger Pluem <rp...@apache.org>.
On 24.03.2009 12:33, Graham Leggett 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.
I guess this is also some of the reasons for discussion here: See if others
speak up and say: Hey I need it for my project XY as well.
> There is no way you could ever have two LDAP toolkits in the same
> address space anyway.
>
> The LDAP C API is a (draft) standard:
>
> http://www.ietf.org/proceedings/01mar/I-D/ldapext-ldap-c-api-05.txt
>
> As a result, all LDAP libraries export the same symbols, and therefore
> cannot coexist in the same address space by definition.
>
> If the initiative to change the LDAP API is an attempt to load two LDAP
> libraries into the server at once, then people need to familiarise
> themselves with the LDAP C API first, before trying to push for major
> surgery to solve a problem we don't have.
>
> 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.
I guess this would be a very valuable step for keeping it in APR (if not
the only step required). By this we can avoid the consumer of APR to be directly
dependent on the LDAP toolkit by pulling in the LDAP toolkit library
dependencies via the APR library. So it should be possible to compile against
APR with toolkit A and use it on a box that has APR installed compiled against
toolkit B. IMHO that would be a real abstraction of the LDAP interface.
And yes you are correct: You can never use two different LDAP toolkits in
the same process at the same time.
This was also clear from the discussion we had here in Amsterdam but not
mentioned on list yet.
Regards
Rüdiger
Re: [VOTE] LDAP in APR 2.x?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Mar 24, 2009 at 12:33 PM, Graham Leggett <mi...@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.
Re: [VOTE] LDAP in APR 2.x?
Posted by Graham Leggett <mi...@sharp.fm>.
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.
> assert(new open source software assumes OpenLDAP)
Does OpenLDAP run on Windows? (I would imagine not, considering Windows
has its own native LDAP stack). Does OpenLDAP support Mozilla NSS?
(strategic direction of the Fedora distro).
> assert(LDAP support in apr won't increase adoption of apr)
Not sure how this is relevant?
> 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.
The LDAP C API is a (draft) standard:
http://www.ietf.org/proceedings/01mar/I-D/ldapext-ldap-c-api-05.txt
As a result, all LDAP libraries export the same symbols, and therefore
cannot coexist in the same address space by definition.
If the initiative to change the LDAP API is an attempt to load two LDAP
libraries into the server at once, then people need to familiarise
themselves with the LDAP C API first, before trying to push for major
surgery to solve a problem we don't have.
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.
> 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)?
Regards,
Graham
--
Re: [VOTE] LDAP in APR 2.x?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
>
> 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.
I agree, it seems apr_ldap can be entirely in mod_ldap.
The existence of mod_ldap is symptomatic of the fact that the apr-util
implementation is not useful. If people want ldap accessors, the mod_ldap
code is AL 2.0 and easily integrated/scrapped.
From the date someone suggested 'let's just not recommend Win LDAP
anymore', I've been of a mind that we are no longer solving problems
in our implementation.
Time to scuttle this, IMHO.
Bill
Re: [VOTE] LDAP in APR 2.x?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Mar 24, 2009 at 11:26 AM, Justin Erenkrantz
<ju...@erenkrantz.com>wrote:
> So, during the conversations we've had here in Amsterdam regarding
> combining APR and APR-util (see post from Paul), one of the big
> stumbling blocks has been our treatment of the LDAP interfaces via
> APR-util.
>
> The crux of the issue is that it is a 'leaky' abstraction - in that,
> APR-util does not currently *fully* wrap the LDAP interfaces -
> instead, it is viewed as augmenting the standard LDAP APIs with
> treatment for LDAP-SSL, etc, etc. This middle ground doesn't really
> suit the APR philiosophy - cf. DBD and DBM interfaces.
>
> Therefore, the consensus of the folks here is that we should pursue
> one of the following courses of action:
>
> [ ] Fix the LDAP interface to be a complete/full LDAP abstraction
> [ ] Remove the LDAP interfaces from APR
>
any counter-knowledge/opinions on the following?
assert(only httpd uses apr LDAP)
assert(new open source software assumes OpenLDAP)
assert(LDAP support in apr won't increase adoption of apr)
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)
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.
Re: [VOTE] LDAP in APR 2.x?
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 3/24/2009 at 4:26 AM, in message
<5c...@mail.gmail.com>, Justin
Erenkrantz <ju...@erenkrantz.com> wrote:
> So, during the conversations we've had here in Amsterdam regarding
> combining APR and APR-util (see post from Paul), one of the big
> stumbling blocks has been our treatment of the LDAP interfaces via
> APR-util.
>
> The crux of the issue is that it is a 'leaky' abstraction - in that,
> APR-util does not currently *fully* wrap the LDAP interfaces -
> instead, it is viewed as augmenting the standard LDAP APIs with
> treatment for LDAP-SSL, etc, etc. This middle ground doesn't really
> suit the APR philiosophy - cf. DBD and DBM interfaces.
>
> Therefore, the consensus of the folks here is that we should pursue
> one of the following courses of action:
>
[x ] Fix the LDAP interface to be a complete/full LDAP abstraction
[ ] Remove the LDAP interfaces from APR
Re: [VOTE] LDAP in APR 2.x?
Posted by Issac Goldstand <ma...@beamartyr.net>.
>>
>> [ ] Fix the LDAP interface to be a complete/full LDAP abstraction
>> [X] Remove the LDAP interfaces from APR
>>
Re: [VOTE] LDAP in APR 2.x?
Posted by Mladen Turk <mt...@apache.org>.
Justin Erenkrantz wrote:
>
> [ ] Fix the LDAP interface to be a complete/full LDAP abstraction
> [X] Remove the LDAP interfaces from APR
>
Regards
--
^(TM)
Re: [VOTE] LDAP in APR 2.x?
Posted by Sander Striker <s....@striker.nl>.
On Tue, Mar 24, 2009 at 12:39 PM, Graham Leggett <mi...@sharp.fm> wrote:
> Justin Erenkrantz wrote:
>
>> Of course not, that's why I posted.
>>
>> The clear consensus here in the room is that the current approach to
>> LDAP is broken and ill thought-out (for the reasons I illuminated),
>> but what there isn't consensus on is how to proceed. Hence, the
>> discussion on-list about how to proceed. -- justin
>
> Votes follow the discussion, they don't precede it.
They can start one, witness this thread. When there is a general idea
that consensus is around the corner, but to not just do it, I think
it's perfectly valid to open like this.
> What is clear is that there is a wide lack of understanding of how the IETF
> draft LDAP C API works, and before people can suggest possible solutions,
> first everyone needs to fully understand the problem they are trying to
> solve.
This is about how technology X (read: LDAP) is wrapped in apr-util,
not about how LDAP works or what problems it addresses.
Cheers,
Sander
> Regards,
> Graham
> --
>
Re: [VOTE] LDAP in APR 2.x?
Posted by Graham Leggett <mi...@sharp.fm>.
Justin Erenkrantz wrote:
> Of course not, that's why I posted.
>
> The clear consensus here in the room is that the current approach to
> LDAP is broken and ill thought-out (for the reasons I illuminated),
> but what there isn't consensus on is how to proceed. Hence, the
> discussion on-list about how to proceed. -- justin
Votes follow the discussion, they don't precede it.
What is clear is that there is a wide lack of understanding of how the
IETF draft LDAP C API works, and before people can suggest possible
solutions, first everyone needs to fully understand the problem they are
trying to solve.
Regards,
Graham
--
Re: [VOTE] LDAP in APR 2.x?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Mar 24, 2009 at 11:52 AM, Graham Leggett <mi...@sharp.fm> wrote:
> Development of APR doesn't happen via conversations in Amsterdam.
Of course not, that's why I posted.
The clear consensus here in the room is that the current approach to
LDAP is broken and ill thought-out (for the reasons I illuminated),
but what there isn't consensus on is how to proceed. Hence, the
discussion on-list about how to proceed. -- justin
Re: [VOTE] LDAP in APR 2.x?
Posted by Graham Leggett <mi...@sharp.fm>.
Paul Querna wrote:
> It will always be in the subversion history.
>
> If its redone and isn't a leaky abstraction, then sure, we can look at
> bringing it back, this vote doesn't stop that from happening.
>
> This vote is about what we want to do in the short term, and frankly
> the LDAP stuff has staggered around for years, and the split between
> mod_ldap and apr-util/ldap has never made sense to me.
>
> Either APR needs to wrap the whole thing, or it shouldn't at all,
> where we are today just causes trouble. It doesn't matter than LDAP
> is a standard. Lots of things are 'standard' APIs, but different
> implementations will still manage to mess it up, and I don't see LDAP
> as being any different in that regard.
>
> So, again, this is about what we are doing NOW, it doesn't prevent
> anyone from coming back to LDAP in the future and doing it 'right',
> for whatever value of 'right' it might have.
In that case we agree.
Two things I'd like to ensure that happen are:
- When I get a chance to set aside some time to sort out the LDAP
abstraction, I don't want to find people saying afterwards "oh, but I
thought we weren't doing LDAP any more"; and
- When end users suddenly see LDAP not-there in apr-2.0, and ask "and
now?", we have a clear story to tell them, and not just leave them in
the lurch.
(It is for this second reason why these kind of discussions need to be
done on-list, because someone is going to suddenly start trawling the
mailing list history for the reasons why apr-2.0 isn't supporting an API
they rely on, and without any history they will be left in the dark).
Regards,
Graham
--
Re: [VOTE] LDAP in APR 2.x?
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 3/24/2009 at 7:47 AM, in message
<42...@mail.gmail.com>, Paul Querna
<pa...@querna.org> wrote:
> On Tue, Mar 24, 2009 at 2:23 PM, Graham Leggett <mi...@sharp.fm> wrote:
>> William A. Rowe, Jr. wrote:
>>
>>> We've actually discussed this on list for several years, and your comments
>>> for years have been 'yea, that's on me, I aught to fix that'. Now that
>>> some folks would like to move forwards towards completing APR 2.0, there
>>> will be more of these sorts of votes.
>>
>> A far more pragmatic approach to this problem is this:
>>
>> "We want to combine apr and apr-util into apr-2.0, but we don't want to go
>> to the effort of moving across apr-ldap, because there are moves afoot to
>> have this abstraction redone. Can we move everything else, and leave
>> apr-ldap in a legacy branch until someone has the time to get this done
>> right for apr-2.0?".
>>
>> Calling for a vote saying that APR will stop supporting LDAP entirely is not
>> a pragmatic approach to this problem.
>
> It will always be in the subversion history.
>
> If its redone and isn't a leaky abstraction, then sure, we can look at
> bringing it back, this vote doesn't stop that from happening.
>
> This vote is about what we want to do in the short term, and frankly
> the LDAP stuff has staggered around for years, and the split between
> mod_ldap and apr-util/ldap has never made sense to me.
>
> Either APR needs to wrap the whole thing, or it shouldn't at all,
> where we are today just causes trouble. It doesn't matter than LDAP
> is a standard. Lots of things are 'standard' APIs, but different
> implementations will still manage to mess it up, and I don't see LDAP
> as being any different in that regard.
>
> So, again, this is about what we are doing NOW, it doesn't prevent
> anyone from coming back to LDAP in the future and doing it 'right',
> for whatever value of 'right' it might have.
Either put it all in mod_ldap or wrap it all in APR but don't push it off to the side again. That happened back in the early days of APR-util which made it difficult to build and deploy auth-ldap. It also left ldap basically abandon because there were only a few of us who cared to develop the code even though there were a lot who cared to use it. I don't know if apr_ldap is used outside of httpd or not but one of the two projects (httpd or apr) needs to continue with it and do it right. Pushing off to the side isn't a solution.
Brad
Re: [VOTE] LDAP in APR 2.x?
Posted by Paul Querna <pa...@querna.org>.
On Tue, Mar 24, 2009 at 2:23 PM, Graham Leggett <mi...@sharp.fm> wrote:
> William A. Rowe, Jr. wrote:
>
>> We've actually discussed this on list for several years, and your comments
>> for years have been 'yea, that's on me, I aught to fix that'. Now that
>> some folks would like to move forwards towards completing APR 2.0, there
>> will be more of these sorts of votes.
>
> A far more pragmatic approach to this problem is this:
>
> "We want to combine apr and apr-util into apr-2.0, but we don't want to go
> to the effort of moving across apr-ldap, because there are moves afoot to
> have this abstraction redone. Can we move everything else, and leave
> apr-ldap in a legacy branch until someone has the time to get this done
> right for apr-2.0?".
>
> Calling for a vote saying that APR will stop supporting LDAP entirely is not
> a pragmatic approach to this problem.
It will always be in the subversion history.
If its redone and isn't a leaky abstraction, then sure, we can look at
bringing it back, this vote doesn't stop that from happening.
This vote is about what we want to do in the short term, and frankly
the LDAP stuff has staggered around for years, and the split between
mod_ldap and apr-util/ldap has never made sense to me.
Either APR needs to wrap the whole thing, or it shouldn't at all,
where we are today just causes trouble. It doesn't matter than LDAP
is a standard. Lots of things are 'standard' APIs, but different
implementations will still manage to mess it up, and I don't see LDAP
as being any different in that regard.
So, again, this is about what we are doing NOW, it doesn't prevent
anyone from coming back to LDAP in the future and doing it 'right',
for whatever value of 'right' it might have.
Re: [VOTE] LDAP in APR 2.x?
Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. wrote:
> So it sounds that you will accept copying apr-ldap into a sandbox and
> would like to continue to pursue it and come up with something workable.
>
> In the meantime, the /repos/asf/apr/apr-util/trunk/ WILL disappear with
> nothing but a SEE_OTHER file. So we can certainly point to where that
> code has disappeared.
+1.
Regards,
Graham
--
Re: [VOTE] LDAP in APR 2.x?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Graham Leggett wrote:
>
> A far more pragmatic approach to this problem is this:
>
> "We want to combine apr and apr-util into apr-2.0, but we don't want to
> go to the effort of moving across apr-ldap, because there are moves
> afoot to have this abstraction redone. Can we move everything else, and
> leave apr-ldap in a legacy branch until someone has the time to get this
> done right for apr-2.0?".
Not quite but close; the right answer is to fork apr-ldap into a sandbox
and let anyone play with it who would like to.
If there is ever a proposal that meets with the project's approval, then
it can ALWAYS be added into 2.1.0 or 3.0 or whatever, provided the API
versioning rules are observed.
> Calling for a vote saying that APR will stop supporting LDAP entirely is
> not a pragmatic approach to this problem.
So it sounds that you will accept copying apr-ldap into a sandbox and
would like to continue to pursue it and come up with something workable.
In the meantime, the /repos/asf/apr/apr-util/trunk/ WILL disappear with
nothing but a SEE_OTHER file. So we can certainly point to where that
code has disappeared.
Re: [VOTE] LDAP in APR 2.x?
Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. wrote:
> We've actually discussed this on list for several years, and your comments
> for years have been 'yea, that's on me, I aught to fix that'. Now that
> some folks would like to move forwards towards completing APR 2.0, there
> will be more of these sorts of votes.
A far more pragmatic approach to this problem is this:
"We want to combine apr and apr-util into apr-2.0, but we don't want to
go to the effort of moving across apr-ldap, because there are moves
afoot to have this abstraction redone. Can we move everything else, and
leave apr-ldap in a legacy branch until someone has the time to get this
done right for apr-2.0?".
Calling for a vote saying that APR will stop supporting LDAP entirely is
not a pragmatic approach to this problem.
Regards,
Graham
--
Re: [VOTE] LDAP in APR 2.x?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Graham Leggett wrote:
>
> This vote is completely premature.
>
> What was supposed to happen is that a discussion be kicked off **on the
> mailing list**, so that people fully understand why the LDAP abstraction
> is as it is, and in turn people can come up with a properly thought out
> way forward to address the issues within it.
Dude, you are on a mailing list.
I just participated, as anyone might, by posting to the mailing list, and
answered (without voting yet) about my opinion.
I'm in AMS but have yet to sit down at the hackathon. Since my opportunity
to voice an opinion isn't hampered by my not being f2f with Paul or Justin
today, I'd argue yours isn't, either.
We've actually discussed this on list for several years, and your comments
for years have been 'yea, that's on me, I aught to fix that'. Now that
some folks would like to move forwards towards completing APR 2.0, there
will be more of these sorts of votes.
Bill
Re: [VOTE] LDAP in APR 2.x?
Posted by Graham Leggett <mi...@sharp.fm>.
Justin Erenkrantz wrote:
> So, during the conversations we've had here in Amsterdam regarding
> combining APR and APR-util (see post from Paul), one of the big
> stumbling blocks has been our treatment of the LDAP interfaces via
> APR-util.
>
> The crux of the issue is that it is a 'leaky' abstraction - in that,
> APR-util does not currently *fully* wrap the LDAP interfaces -
> instead, it is viewed as augmenting the standard LDAP APIs with
> treatment for LDAP-SSL, etc, etc. This middle ground doesn't really
> suit the APR philiosophy - cf. DBD and DBM interfaces.
>
> Therefore, the consensus of the folks here is that we should pursue
> one of the following courses of action:
>
> [ ] Fix the LDAP interface to be a complete/full LDAP abstraction
> [ ] Remove the LDAP interfaces from APR
This vote is completely premature.
What was supposed to happen is that a discussion be kicked off **on the
mailing list**, so that people fully understand why the LDAP abstraction
is as it is, and in turn people can come up with a properly thought out
way forward to address the issues within it.
Development of APR doesn't happen via conversations in Amsterdam.
-1.
Regards,
Graham
--
Re: [VOTE] LDAP in APR 2.x?
Posted by Bojan Smojver <bo...@rexursive.com>.
On Wed, 2009-03-25 at 01:34 +0200, Graham Leggett wrote:
> mod_ldap is an LDAP cache, it isn't an LDAP abstraction layer (that's
> what apr-ldap is for).
I meant, maybe there is code in there that already abstract a lot of
that stuff, which can then be reused, given it works with many LDAP
implementations. I haven't actually looked at the code at all.
--
Bojan
Re: [VOTE] LDAP in APR 2.x?
Posted by Graham Leggett <mi...@sharp.fm>.
Bojan Smojver wrote:
>> [x] Fix the LDAP interface to be a complete/full LDAP abstraction
>> [ ] Remove the LDAP interfaces from APR
>
> Provided most of the code can be taken from mod_ldap. In other words,
> more people can use it if it is in APR.
>
> But, if it is hard to do (i.e. if mod_ldap doesn't abstract this nicely
> already, so it would take a lot of work to put it in APR), I won't be
> crying about it.
mod_ldap is an LDAP cache, it isn't an LDAP abstraction layer (that's
what apr-ldap is for).
Anything toolkit or platform specific in mod_ldap is a bug.
Regards,
Graham
--
Re: [VOTE] LDAP in APR 2.x?
Posted by Bojan Smojver <bo...@rexursive.com>.
On Tue, 2009-03-24 at 11:26 +0100, Justin Erenkrantz wrote:
> [x] Fix the LDAP interface to be a complete/full LDAP abstraction
> [ ] Remove the LDAP interfaces from APR
Provided most of the code can be taken from mod_ldap. In other words,
more people can use it if it is in APR.
But, if it is hard to do (i.e. if mod_ldap doesn't abstract this nicely
already, so it would take a lot of work to put it in APR), I won't be
crying about it.
--
Bojan