On 04 Jul 2011, at 6:48 PM, Joe Orton wrote:
It's incumbent on you to provide specific technical objections if
vetoing code, not this hand-waving "objections must exist because of
X".
I have already done so. If you disagree with the objection, or do not
understand the objection, engage the objection directly so it can be
resolved.
The removal from APR was because the API does not match design of the
other APIs in APR, because it is an "incomplete abstraction" -
mod_ldap
must use the underlying LDAP API directly as well as the wrapper
functions. This is not something which translates directly across to
httpd; the exported API from mod_ldap was already an incomplete
abstraction, adding more exports does not change that. Indeed, it
explains the motivation for consolidating this stuff in one place.
We are not discussing the removal of apr_ldap from APR, we are
discussing the addition of ap_ldap to httpd.
Wrowe's reasons for removing apr_ldap from APR are very valid and
real, the incomplete abstraction is wrong, and sf has already
explained the problems that are caused when libraries and/or modules
compiled with different LDAP library are linked to the same server.
These problems are not in any shape or form solved by moving apr_ldap
to httpd, the move serves no purpose whatsoever. Over and above this
zero nett gain, we now have two nett losses:
- We now suffer an abstraction API in httpd, when all other
abstraction APIs are in APR. I personally don't care whether the
abstraction libraries are in APR proper, in apr-util, in apr-ldap or
httpd-helper-libraries, what I do care is that all abstraction APIs
should be treated the same way. I have not seen any discussion to
suggest that there are any plans to move DBD, DBM, crypto and XML, nor
have I seen anyone justify why we are using an inconsistent approach
in our architecture.
- We currently build against 7 different LDAP APIs on a multitude of
different platforms. Without the courtesy of any warning or
discussion, maintainers of various platforms are now expected to spend
their time and money making this code build again in the httpd
codebase. What is the payoff for them? Nothing.
Wrowe has attempted to justify his addition of ap_ldap to httpd by
saying "because httpd would not have been happy if it had abandoned
these helpers and
they were not present for httpd's consumption", however this statement
is not true - LDAP is present in apr-util, and will always be present
as per the versioning rules of APR.
In addition, the versioning rules of apr-util allow us to add to the
API and in so doing complete the abstraction, solving the problem in
apr-util v1.4 or v1.5. That makes this entire move unnecessary and a
huge waste of time.
I am confident that the httpd people will address the APR v2.0 LDAP
issue, but only after httpd v2.4 is baked, people have time again, and
APR v2.0 starts becoming something less than vapourware.
If you have specific concerns with exposing all the ap[r]_ldap_* API
from httpd, then that is something we can maybe resolve; it looks like
mod_authnz_ldap and mod_vhost_ldap only require the url_parse hook, so
maybe we could cut the additional exported API back down to that?
A cut down LDAP API is useless to anybody wishing to bind to an LDAP
API and use its complete functionality, unless the API is complete, we
are wasting the end user's time.
Long ago we moved away from this portability nonsense, delegating the
job to APR. Moving this all back to httpd is ugly in the extreme.
You allude to build issues without giving details, what's still
broken?
(Thanks Stefan for fixing my own screwup)
See at least the following threads:
- Thread ending with "[VOTE REVOKED] Re: [VOTE] Release Apache
httpd-2.3.13 as beta"
- httpd LDAP mess
In the case of MacOSX, it breaks for me as follows:
checking whether to enable mod_authnz_ldap... checking dependencies
checking whether to enable mod_authnz_ldap... configure: error:
mod_authnz_ldap has been requested but can not be built due to
prerequisite failures
Regards,
Graham
--
