httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: load order dependency between mod_ldap and mod_authnz_ldap
Date Fri, 08 Jul 2011 02:10:36 GMT

On 25 Jun 2011, at 21:11, Graham Leggett wrote:

> This is not so, to fix this, you would need to wrap every single LDAP API function call[1]
in an optional function, and if you did that, you would solve the problem that caused you
to want to remove apr_ldap from APR in the first place, making the whole exercise pointless
- you may as well just have fixed apr-ldap in place.

In view of the escalation of this argument, I'm trying to review the history and see
if I can get to grips with the underlying problem.  It seems this is where your
objection starts, right?  If it matters, I'm trying not to take sides here, and I too
find it uncomfortable when Bill gets abrasive in a public list.

But isn't the above a slight misstatement of the issue?  ap_ldap (and apr_ldap before)
wraps only a subset of the LDAP API, that subset is what in fact has to be wrapped in
optional functions.  I don't see a problem with that: more optional functions can be
introduced as and when more APIs are exposed.  And optional functions can exist
alongside regular API functions, as in mod_dbd.h, as and when you or anyone do it.

> The timing cannot be worse - an already suboptimal API plus these new bugs are being
dumped into httpd in the final stages of trying to bake the final version of httpd v2.4.0,
which means we will be stuck with this brokenness through the life of httpd v2.4.

Up to a point.  We're full of compromises, some nicer, some uglier.
But what *new* bugs are you referring to that aren't fixed by optional functions?
Would it make sense to introduce a mod_dbd-like parallel API, and does it break
anything that would prevent you hacking it within the lifetime of 2.4?

> There is no need for this move at all, as httpd works perfectly against APR v1.x (or
did until this change). APR v2.x hasn't gone through any kind of stabilisation phase, never
mind seen an alpha or beta release, and so httpd v2.4.x being compatible with apr-trunk at
this stage is not necessary, especially seeing that when httpd v2.4 is released, it's API
is set in stone, but APR v2.0's API remains in flux. Or to put it another way, the fact that
apr_ldap is missing from apr-trunk is not a problem for httpd v2.4, and can be solved after
httpd v2.4.

That's a fair point.  If you can convince me there are NEW unsolved bugs,
I may support it.  But I wouldn't agree with excluding APR2 use if these
new bugs are (no more than) what optional functions solve.  Nor do I
think now is the right time to make an issue of defects that are equally
present in ap_ldap and in apr_ldap before.

> I am therefore vetoing this move of apr_ldap from APR to httpd.

Hang on!  How long ago did this move happen, and when did you
first raise concerns?

Nick Kew

Available for work, contract or permanent

View raw message