httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: load order dependency between mod_ldap and mod_authnz_ldap
Date Sun, 03 Jul 2011 21:13:37 GMT
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
--


Mime
View raw message