On 6/2/2011 5:51 PM, Graham Leggett wrote: > On 02 Jun 2011, at 4:19 PM, William A. Rowe Jr. wrote: > >> Graham, I am not, I repeat, not discussing your *contribution* to the ASF. >> I respect the many, many things you have added, and aspects you improved, >> and bugs you have fixed, which includes your patches to ldap. > > I have asked repeatedly for you to provide feedback on the apr_crypto APIs > and to properly > articulate your long standing objection, and you left both myself and the > project waiting > ages before you finally did so. I assumed the reason for this was that you > were just busy. > When you finally did provide feedback it turned out you had completely missed > that fact > that the a key part of your objection had been fixed on trunk 12 months > earlier. I assumed > your email was broken, or you had just missed that earlier patch to trunk, > perhaps again > because you were too busy, or perhaps it was a simple mistake.
Agreed, I had overlooked this. The reason for my delay is not the apr_crypto API anymore, however. The apr_crypto API discussion drew my attention to other API's which slipped in with some odd arglists that didn't follow the style of the original library (particularly through the apr_util path). So I actually have a library-wide review of all of our interfaces and a document to write which spells out the style, particularly to C coders who might find the C++ style argument list conventions a bit unusual (**result as first arg of constructors, *this as first arg of most methods, etc). I can only do one bit at a time, be it fix win32 build for httpd against 2.0, or fix ldap (which I believed was decided, see next), or figure out what 2.0 will do in the absence of apr-iconv (perhaps optional use of libiconv), or whichever. And yes, I'm busy, so my contributions have been bursty and to whatever is my largest itch at the moment, and last weekend it was to have an entirely apr 2.0-ready httpd trunk flavor. apr_ldap was voted away twice so I had no clue it would start a flamewar. > In contrast, you didn't show me the courtesy of asking me for feedback on the > state of > apr_ldap code, to clarify whether there were any blockers, or whether there > was anything > you could do to speed things along. Instead you assumed I "couldn't be > bothered" and > declared as much on a public mailing list, after taking matters into your own > hands > ripping out the old code. In doing so, and despite your denial above, you > have made your > feelings on my contribution to the ASF quite clear. That's only because when the issue was raised in 2010, there was no word that future changes were in store. It was a pretty cut and dried answer from the list, and you didn't respond. So I don't think I was out of line in just assuming that there was nobody working on this code any longer. > I am a member of the APR PMC, and a long standing member of the foundation, > and this is > because I care about the APR project, I care about other projects at the ASF, > I care about > the foundation, and I care about the end users and vendors who use our > software. For this > reason, I will continue the work on apr_crypto, followed by the work on > apr_dbd, followed > by apr_ldap, as agreed by this project in the past, until the agreed work is > complete, no > matter how unpleasant the task turns out to be. I however respectfully ask > that you make > this task no more unpleasant for me than it needs to be. If we are blocking on you, or me, this isn't tenable. crypto is the first because we have collectively studied this and want it done. dbd, or more precisely the master list of exceptions, would be second, but don't feel that you own responsibility to fix those. These are implementations which don't suffer the incompleteness issues, but simply need arglist and naming convention normalization. Those I'm going to chew on one API at a time, but you and I are not the only two who could contribute to this. The precise definition of how to fix apr_ldap (exporting all of the entry points which a simple apr consumer would require) has been clarified years ago and there is no effort towards this. If there are *3* committers to support it, and more than one use case, the project would consider admitting an implementation for apr 2. In the interim, I'm reading your frustration, and your venting, but have not read your response to the simple question... where are the consumers outside of httpd mod_authnz_ldap? Jeff asks this question sincerely. And I am confused with one thing. apr_crypto called out issues which cause apr_dbd arg lists to be reevaluated. However, that is not the complaint with apr_ldap, but I think you might be conflating them? If the arg lists to apr_ldap were an issue, I would have simply proposed the corrections. apr_ldap's issue is that it is an incomplete interface. It is useless without intimate knowledge and use of the system LDAP provider, per the standard ldap API. Therefore, whomever consumes apr_ldap must ***also*** consume the system/toolkit ldap support, and that which apr was built against, to be specific.
