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: r329089 - in /apr/apr-util/trunk: build.conf include/apr_memcache.h memcache/ memcache/apr_memcache.c
Date Fri, 28 Oct 2005 06:51:36 GMT
Paul Querna wrote:
> William A. Rowe, Jr. wrote:
>>pquerna@apache.org wrote:
>>>Author: pquerna
>>>Date: Thu Oct 27 21:23:01 2005
>>>New Revision: 329089
>>>URL: http://svn.apache.org/viewcvs?rev=329089&view=rev
>>>Import apr_memcache trunk to APR-Util.
>>>Still TODO:
>>>- Move CRC32 to a separate public function/API.
>>>- Create a multi-get interface.
>>>- Make locking and connection pooling optional.
>>For the moment, -1, please revert and begin an apr-memcache sandbox
>> * it makes trunk/ unstable, preventing us from moving to 1.3
> Then branch 1.3 and revert in the branch.  Trunk should always be safe
> to commit to, IMHO.

Is apr_memcache.h your final answer?  None of those API's will change?  I read
your TODO as a list of items that might change.  You can't do that on trunk,
only the 'final' API can be committed to trunk; we are stuck with it till 2.x.

svn is lovely, we can create all the sandboxes we need to put together 'final'
solutions that are ready to merge for the next minor bump.

>> * this seems entirely too specialized (in other words, useless code bloat)
>>   All of the concepts here -are- useful, but not in this aggregation.
> I disagree.  I think many others disagree.  We voted on this 4 days ago,
> everyone who voted approved. It would of been helpful to see your
> opinion then.  I understand we are all busy, but this feels like going
> backwards in the discussion.  Its not bad, it just would of been nice to
> raise these concerns in the vote thread.

Sure, so next time leave the vote for major changes open more than four
days.  I counted four contributor votes in four days, that isn't exactly
a resounding concensus for a major scope change to an ASF project.

Give me the weekend to codify my specific objections and raise some
possible solutions.

>> * if we trust that this code is incomplete (my objections and your TODO)
>>   then we have to partition it off for a while, till it's fleshed out.
>>   With ABI/API stability a prime concern, dropping in an interface that
>>   the group will suggest improvements and code style corrections for, is
>>   a bad thing in a live 1.x release at this stage of it's development.
> The code is complete. There is no API instability. It has been stable as
> a separate project for nearly a full year.
> My TODO that I mentioned in the commit log is to ADD features to the
> API. The existing API would not be changed in any way.

Ack, I misunderstood this.

I still look at this as feature creep, an indirect endorsement of some edge
solution that's not based on any std/rfc/ietf/iata/w3c or other standards
body.  It's got a very enthusiastic but narrow audience as it appears to
be a very good solution for specialized (thus far) use cases.

If we can offer an API which provides general utility and multiple solutions,
as opposed to locking users into a very specialized solution, then I'm likely
to endorse it.  Obviously for ssl session caching and dozens of other examples
in httpd, we aren't doing things well, and this merits improvement.

As I said, I need free cycles, something I don't have most workdays, before
I can really spell out my objections.  But this commit definately went in the
opposite direction raised over the last week, that many users already find
apr-util hopelessly twisted into a compile-to-the-target-machine mess, and
are begging us to deliver the truly utilitarian parts of apr-util independently
of all the rest of the cruft.


View raw message