apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
Date Thu, 02 Jun 2011 22:51:30 GMT
On 02 Jun 2011, at 4:09 PM, Jeff Trawick wrote:

> What are the critical facts?
>
> LDAP support in APR 2.0:
>
> * there was [almost] no support for preserving the status quo; those
> that spoke up wanted either to make it a full API or drop it
> ** more wanted to drop it
> ** Graham offered to do the work to make it a full API
>
> * AFAIK we did not resolve the fact that more people spoke up for
> removal than for making it a full API ("tentative compromise"?)
>
> * nobody got around to either removing it or making it a full API for
> a long time afterwards, for the same multitude of reasons that other
> things do not get done
>
> * wrowe finally got around to take action, which was to yank it
> ** I dunno if that was preceded by a notice, which would have been
> "nice"  (no, I haven't spent much time in my inbox :( )
>
> Any dispute so far?

Yes, you missed out the apr_crypto and apr_dbd API issues that blocked  
apr_ldap.

apr_crypto was written off a direct template of the apr_dbd code under  
the understanding that apr_dbd represented the accepted level of API  
quality in apr. Feedback since the apr_crypto code was committed has  
revealed that apr_dbd does not represent the accepted level of API  
quality in apr, with respect to the passing of multiple context  
pointers at the same time, and the ordering of the parameters, and it  
has been made clear by those expressing their disapproval that this is  
required to be fixed. I agree with them. As you are aware, fixing  
apr_crypto is a top priority, because it blocks apr-util v1.4 and  
httpd v2.4.

Given that the plan was to model the apr_ldap code on apr_dbd, work on  
apr_ldap was suspended until the issues of exactly what was wrong with  
the apr_crypto and apr_dbd APIs was resolved. Most specifically, the  
plan was as follows:

1) apr_crypto gets all required changes made to it, people agree that  
apr_crypto's interface represents the level of quality acceptable to  
the project. Feedback on apr_crypto has been torturously slow, but it  
has at last arrived.

2) apr_dbd gets the same changes applied to it to bring it to the new  
standard required of apr_crypto, people agree that apr_dbd's interface  
represents the level of quality acceptable to the project.

3) apr_ldap gets written from scratch, carefully ensuring as little  
disruption for the 7 different toolkits we support (ie we leave the  
autoconf stuff alone, as it already works, the API is a problem),  
again with an interface consistent with apr_crypto/apr_dbd, and to the  
level of quality acceptable to the project.

Where are we right now? We're still at step one above. Wrowe has after  
a long delay provided an apr_crypto.h file that represents the  
blueprint for what he believed was wrong with the apr_crypto and  
apr_dbd APIs, and his issues have been recently fixed. These have been  
backported to apr-util v1.5 and v1.4. Further polishing has taken  
place, and these too need backporting, and I planned to have this  
resolved this week while trying to have a holiday.

The work on apr_dbd was to happen next, but wrowe expressed his  
preference to wait until httpd v2.4 was out the door (no objection  
from my side). My plan was to propose a new apr_dbd API within the  
comments of apr_dbd, giving people the opportunity to agree on the  
changes in principle before they were applied in practice. I was not  
prepared to start the work on apr_ldap until I had a solid and agreed  
template on which to build upon, as I am not prepared to repeat the  
torturous process of vague objection followed by endless delay that I  
experienced writing apr_crypto. In the mean time, there is enough work  
to keep me busy on httpd v2.4.

At this point, out of the blue, something snaps and wrowe decides that  
he is tired of waiting for step 3 above, makes the accusation "but you  
had years to set aside time, and couldn't be bothered", as if to say  
that I have been doing nothing all this time (svn disagrees). This  
statement comes after making me wait literally years for a clear and  
unambiguous answer as to exactly what is wrong with the apr_crypto and  
apr_dbd APIs, so that I could move forward on the plan above.

As a project, we need to work together, we need to collaborate.

The right thing to have done would have been to have asked on the list  
as to the status of apr_ldap, and what was blocking progress. The  
answer to that question is written above, and would have been provided  
had somebody just asked.

Regards,
Graham
--


Mime
View raw message