On 27 Jun 2011, at 12:28 PM, Joe Orton 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.
mod_authnz_ldap is an existence proof that we don't need to wrap every
LDAP API function call for mod_ldap to be useful in its current form,
surely?
mod_ldap - An LDAP shared memory cache
mod_authnz_ldap - A user of the LDAP shared memory cache
The LDAP API exposes way more functionality than mod_ldap exposes, so
while you may have fixed the problem for the special case that is
mod_authnz_ldap, you won't have fixed the problem for any other module
that makes LDAP calls directly.
The v1.x LDAP API was removed from APR because it was an incomplete
abstraction, and for this exact same set of reasons it is
inappropriate to add it to httpd.
Over and above that, given that httpd has no library component common
to all modules (well, it has, it's called APR), and given that the
httpd core is inappropriate for an LDAP portability library, the only
place to put the LDAP bindings is in mod_ldap, which means we either
have to accept the module ordering problems that result, or we have to
create optional functions for every single LDAP API call, and if we do
that, we end up solving the reason apr_ldap was removed from APR in
the first place.
In addition, we moved all portability code out of httpd in v2.0, it is
a huge step backwards to go back on that effort. It is really ugly to
have apr_xml, apr_dbd, apr_crypto and apr_dbm in APR, and then
ap(r)_ldap somewhere else.
This is the essence of my veto.
The timing cannot be worse
This is probably true, but it doesn't seem like technical
justification
for a veto. Release schedules can move at the pace we want them to.
This was an observation, not part of the veto. It's important because
there are people who are really keen to get v2.4 out the door, and
this means practically is that a suboptimal API is being rushed
unnecessarily into GA, and that is really really bad.
There is no need for this move at all
This is strictly true, in the sense that there may be other ways to
solve the problems fixed by moving the code. If other solutions are
presented, we can have a consensus vote on which to choose. In the
absence of other solutions being implemented, asserting that "better
solutions exist" can never be sufficient reason to veto a change.
The solution we agreed on in the past was to rewrite apr_ldap to fit
the pattern of apr_dbd, but this effort was held up by a whole lot of
problems in the apr_dbd API that were identified during review of the
apr_crypto API, which was modeled on the apr_dbd API. This effort was
also held up by the focus on getting httpd v2.4 out the door.
wrowe got impatient and removed apr_ldap from apr-trunk, which on the
face of it isn't a problem for httpd because apr-trunk isn't a
released entity yet, nor is it likely to be until the issues with
apr_dbd (and as I understand apr_dbm) are fixed (among other issues).
This move just forces us to solve the apr_ldap issue before apr v2.0
is released. It doesn't however put httpd under any obligation to take
any drastic measures for httpd v2.4, because the existing apr_ldap
library exists and is supported in apr v1.x.
In short, when httpd v2.4 is released, we will be free to focus our
attention on apr_ldap and get it fixed.
There is no need for any temporary hacks before then (where
"temporary" is defined as "permanently baked into the httpd v2.4 API").
Regards,
Graham
--
