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
--
