On 27 Jun 2011, at 4:04 PM, William A. Rowe Jr. wrote:
And I'd nix your definition of mod_ldap... if it an "ldap shared cache
provider" then it should have been suitably named. One can omit
such a
feature and still use mod_authnz_ldap. Of course, that was not
possible
because mod_authnz_ldap required mod_ldap required the ldap helpers
required an ldap client library.
mod_ldap is an ldap shared memory cache, arguing about what it should
have been named is pointless, it doesn't make it any less so.
I expect anybody hacking on the LDAP code to know what it is and
understand how it works. If you don't have even a basic understanding
of how the existing code works or is structured, it is highly
irresponsible to be attempting wholesale changes to it. You can add
this as yet another reason why I veto your commit.
Please revert your code as soon as possible, to ensure that no more of
this project's time is wasted.
No. We didn't agree upon a solution. We agreed upon a design
pattern.
Precisely, and despite this agreement, you have taken it upon yourself
to ignore this design pattern without any justification or
explanation, repeatedly suggesting and calling for votes out of the
blue on all sorts of badly thought out alternatives for no good reason.
In the amount of time we have wasted on pointless deadend design
discussions, I could have fixed this issue ten times over, and so
could you. I could have also finished outstanding work on apr_crypto,
apr_dbd, apr_dbm and mod_cache.
I have no expectation that it will be fixed,
The only way this statement could possibly be true is if you had no
intention of fixing the problem yourself, in the way that was agreed.
There is no two tier system at the ASF where one group gives orders
and another group follows them, we all collaborate on this project,
together. Nothing stopped you picking up the draft RFC, learning how
the LDAP API worked, and filling in the missing part of the API, and
yet you chose not to. "svn move" does not constitute a meaningful
contribution towards fixing the issues with the LDAP API.
and the majority voted at
APR to evict apr_ldap,
You proposed a vote out of the blue on the APR list to move code to
httpd, without any prior discussion with either the APR or httpd list.
You'd obviously discussed this offline, because two people almost
immediately responded by voting for your move, again without any
discussion or explanation. Everyone else ignored your thread. The
httpd project were never notified at all that the vote had taken
place, never mind their opinions consulted.
As far as procedure is concerned, this vote did not happen.
therefore it is gone (not be veto or fiat, but
by the preference of the majority). I have reacted accordingly
because
httpd would not have been happy if it had abandoned these helpers and
they were not present for httpd's consumption.
Did it cross your mind to check with the httpd project first whether
this assumption was true? I'm sure that the httpd project is overjoyed
at the fact that the latest beta release failed for every person who
tried it after you had dumped the code into the tree without any
warning, any discussion, or any testing. I'm sure we are all
overwhelmed too at having our builds broken out of the blue on pretty
much every single platform that httpd runs on because you left the
build scripts unmodified and untested after the dump.
The httpd project currently depends on and works with the perfectly
functional apr_ldap interface in the current release of apr-util,
which supports 7 different LDAP libraries on a host of different
platforms, and LDAP is not going anywhere in apr-util. There was no
need to make any panicked rush job import of code into the httpd tree,
it was entirely unnecessary.
We have an opportunity to complete the missing parts of the apr_ldap
interface and release apr-util v1.4, and then change mod_ldap and
friends to use those new interface functions before httpd v2.4 goes out.
This represents the simplest and most efficient solution to the
original problem, which was people deploying apr linked to one ldap
library alongside mod_foo_ldap linked to another.
Turning LDAP into a pluggable DBD style API is a desirable addition
for APR v2.0, but makes no practical difference to httpd v2.4, as APR
v2.0 is vapourware.
Regards,
Graham
--
