On 25 Oct 2010, at 11:51 AM, William A. Rowe Jr. wrote:
Wow, the very first contribution to the discussion is a veto, and
you've vetoed code that
doesn't even exist yet. Crickey, the *ideas* behind what code might
be attempted haven't
been fleshed out yet and you're already waving a veto around.
No, I voted against a concept (of throwing everything against the
wall at once),
that wasn't even a veto.
-1 in ASF speak is a veto. When people mention -1 without it being a
veto, they declare it so in brackets. Me personally, I just say "I
disagree" and leave it at that so there is no opportunity for confusion.
If you can find 3 +1's, I already asserted that I'd reverse that
position,
as my primary issue is a lack of review.
A lack of review on a piece of code that doesn't exist yet, within a
discussion that hasn't finished yet, based on research that hasn't
been concluded yet.
The reason I initiated this discussion was that I was hoping that
people would highlight the potential impact of making a change here.
Obviously it's at the core, obviously it needs to be done carefully,
obviously servers with few locations cannot suffer for the benefit of
servers with many. In my experience with the httpd code, most
optimisations are really simple, and involve minimal code changes, a
testament to the careful design that has gone into this code at the
start. I see no reason why future code changes should be any
different. I am dismayed that people who would contribute to this
discussion are scared off by a waving veto.
Right now, I'm staring at development in mod_cache that makes no
sense,
other than bandaids and bubblegum over operational flaws, while we
have
underlying logic between the datastore provider that thinks httpd, and
the mod_cache protocol module which is dealing with storage questions.
And you are asking to refactor *what* next? Eeek!
If you don't understand how the cache works, *ask*.
I designed the thing in the first place. I wrote mod_proxy for v2.0
from scratch in a Swedish hotel room when the filter stack first
appeared, and I took the original 1.3 cache out of mod_proxy into a
separate filter based framework, while others fleshed mod_cache out
until it worked. Can it be done better? Yes, thus the recent work on it.
For us, one of the world's biggest global media networks serving an
audience of tens of millions of people every hour, mod_cache sits in
front of our restful service layer, amongst many other places. We
learned three key things from this experience:
- Many developers for the web don't know what RFC2616 caching is.
Unlike us, starting out when the net ran slower than morse code, some
developers have never encountered a slow net connection before, and
have never had to know or care about a cache. We went on an education
drive, demonstrated the orders of magnitude improvement in speed that
HTTP caching offers in a restful environment, and now our developers
can't get enough of it.
- All the HTTP caches we tried, those built into load balancers, those
built into dedicated proxy servers, and mod_cache, have common edge
case bugs in them, particularly the notorious "leaking 304" problem
caused when developers don't take care of the caching headers they
send with a 304 Not Modified from their RFC2616 conditional request
supporting service. mod_cache's key bugs have been fixed, and it is
now fully RFC2616 compliant, not just selectively so.
- The httpd filter stack rocks, hard. The fact that we can now
selectively insert mod_cache anywhere in the filter stack, rocks even
harder. By "rocks" I mean "saves an enormous amount of money".
If you don't believe the mod_cache provider API is correct, then
identify specific things about the API you do not believe are correct
and allow me to fix them for you. Hand waving descriptions like
"bubblegum" and "operational flaws" are entirely unhelpful and
contribute nothing towards fixing the problems you believe exist.
Understand that wholesale massive reorganisation of the cache will
very likely not get the review it requires, just as you've pointed out
for ap_location_walk(), so distill them down into discrete changes
that can be applied in simple to understand patches.
Anything that involves making mod_cache.h's public interface smaller,
a big +1 to that. We can always refactor the cache internally at a
future date, we can't change a public API after 2.4 has been branched
(until v2.6, obviously). Anything that identifies functions we are
exporting unnecessarily, +1 to that too.
And if we can do the same thing on the excessively-public mod_proxy.h
header, +1 to that too.
What I was trying to say, however untactfully, is that I wouldn't be
very
supportive of the same approach to core code. And reading the rest
of your
reply, I think we are of the same mind.
FWIW I didn't conflate anything, I understood each of the aspects of
the
proposal you put forward as "one change". If you can break down your
proposal into digestible pieces, I'll support any demonstrable
worthwhile
piece you put forward. I'm simply asking for no repeats of the
current
state of cache/proxy/ldap/etc etc. And I don't really think you
disagree.
Pick a piece to discuss, and I'm happy to respond.
Will follow this up in the original thread.
Regards,
Graham
--
