apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
Date Fri, 03 Jun 2011 03:19:59 GMT
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
> 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
> because I care about the APR project, I care about other projects at the ASF, I care
> the foundation, and I care about the end users and vendors who use our software. For
> 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,
> 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.

View raw message