httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c util_filter.c
Date Sat, 02 Sep 2000 15:56:15 GMT

> Do you suddenly have the ability to decide what is a valid veto or not? Do
> you get to decide what is "technical enough" or not? Do you get to decide
> whether my premises are valid?

No, but I do get to decide that after three weeks of asking for a
technical reason (which should prove that I don't see the reason for the
veto) and not recieving ANY response, I can commit without worrying about
it being backed out.  I asked at least three times on the public list if I
could commit the patch to fix the current bugs, and I recieved NO ANSWER
at all.  I finally gave up and tried to move forward.

> We're operating under a set of rules that we accept on a consensual basis.
> It doesn't seem right than an individual can then go and adjust them to suit
> their purposes. If we had that choice, then a veto would be meaningless --
> people could simply argue around it, saying it is invalid for <whatever>
> reason.

No, it doesn't seem right.  And yet, you posted a veto with no real
explanation.  The explanation that kept coming up was "We designed this
together a long time ago."  According to the Apache guidelines:

-1 No. On issues where consensus is required, this vote counts as a
veto. All vetos must include an explanation of why the veto is
appropriate. A veto with no explanation is void.

The explanation of "this is how we designed it", when at least two people
are saying the design is wrong, is not a valid veto.

> If I had said "I don't like that approach" or "it doesn't feel right", then
> sure: it wouldn't be a fair veto. But I think you would need a little
> discussion and consensus before simply declaring it invalid, *even* in that
> ambiguous case. Unilaterally deciding it is invalid and ignoring it is like
> thumbing your nose at our process.

I asked for THREE weeks on new-httpd.  I continually asked for a better
explanation of the veto, and I asked over and over again if I could commit
so that we could move forward.  I NEVER received any answer at all.  After
three weeks, I assumed you either didn't care anymore, or had removed the
veto.  Don't try to change history by saying I just declared it
invalid.  I tried to work within the system for a long time before I just
stepped over the roadblock.

> As I've said: the LIFO thing simply shifts the problem around (rather than
> solving it), and it is backwards from the insert_filters hook.

As I've said over and over again.  The insert_filters hook is bogus, and
it needs to be removed.  It doesn't work at all.  Take the example of
sub-requests.  All requests will be calling the same insert_filters hook,
both main requests and sub-requests.  Because sub-requests inherit main
request filters, this means that all sub-requests will be calling most
filters multiple times, or all insert filters functions must have logic to
ensure that only main requests get the filter.  This is just plain wrong.

> >From those discussion, my understanding was that "insert after <current>"
> was a valid semantic when a *filter* wants to install another. The
> ap_add_filter semantic of "append this filter to the chain" is valid for
> other people to use (since they cannot point at a filter and say "insert
> after <that> one").

But it isn't insert after, it is insert on the top of the stack.  We are
cheating at the stack implementation, because it makes the code easier,
and itg makes sense.  Think of it this way, we start a request, and start
creating the filter stack.




Now, we call mod_include's filter:

The stack really looks like:


but, conceptually, it is


again, because we pop'ed the INCLUDE when we called it.

> Heck, why isn't the chunking filter inserted right at the beginning of the
> request handling? At the point where content finally arrives, it can decide
> "woah. I can't send this particular response using chunked encoding" and
> disable itself. Perfectly valid approach (e.g. let the filter itself decide
> what is right or not) and we wouldn't even be at this juncture.

Yes we would, we just wouldn't be at it right now.  What you are
suggesting, is that ALL filters are added for all requests, and they
remove themselves when they aren't necessary.  That too is bogus.  We
should only be adding filters that will be used.  We want a short filter

> A prepend style doesn't fix this either. You've simply reversed the problem:
> you better prepend them in the correct order. It saves you nothing over the
> explicit notion of groups.

Yes, it doesn't because filters have a natural grouping.  That grouping is
based on what the filter does.  Just by inserting the filter at the most
logical place, we can extend this into the future.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message