Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c util_filter.c

[rb...@covalent.net]

> 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.

CORE

then

INCLUDE
CORE

Now, we call mod_include's filter:

The stack really looks like:

INCLUDE
CORE

but, conceptually, it is

CORE

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
stack.

> 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

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: cvs commit: apache-2.0/src/main http_core.c

[Greg Stein <gs...@lyra.org>]

On Sun, Sep 03, 2000 at 08:44:24AM -0400, Jim Jagielski wrote:
> Rodent of Unusual Size wrote:
> > rbb@covalent.net wrote:
> > > > 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.
> > 
> > Um, no, you don't get to decide that.  Nobody does.
> > 
> Vetos without a supporting rationale aren't really vetos though. I veto
> with the reason "I don't like it" can't be considered a valid veto.

That was Ryan's characterization, not my actual reasoning.

1) The original veto is: <20...@lyra.org>
2) It references: <20...@lyra.org>
3) More veto clarification: <20...@lyra.org>
4) Additional response: <20...@lyra.org>

<the checkin-in-question occurred>

5) I clarified/reiterated my reasoning in: <20...@lyra.org>
6) And one more time: <20...@lyra.org>


I believe that is all that I sent on the matter based on my quick search.
But I've always felt that it was enough and provided enough reasoning. It
was never a simple "I don't like that" veto. I also agree that any veto
needs some support. In this case, Ryan felt my reasoning was invalid and
ignored the veto.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.cutil_filter.c

[Rodent of Unusual Size <Ke...@Golux.Com>]

rbb@covalent.net wrote:
> 
> > > 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.
> >
> > Yes, it is.  The proper response is to post a correction to the
> > design, not patches to the code.
> 
> The changes to the design were posted.  I posed design changes, and a
> patch one day, and then an updated patch the next day.

And if there wasn't consensus that the design changes were correct
and acceptable, they don't take effect automatically.
-- 
#ken    P-)}

Ken Coar                    <http://Golux.Com/coar/>
Apache Software Foundation  <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed"   <http://ApacheUnleashed.Com/>

Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.cutil_filter.c

[rb...@covalent.net]

> > 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.
> 
> Yes, it is.  The proper response is to post a correction to the
> design, not patches to the code.

The changes to the design were posted.  I posed design changes, and a
patch one day, and then an updated patch the next day.

> Can you please post the message IDs of these multiple requests
> for clarification you made?  I can't find them..

I'll post them later today.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.cutil_filter.c

[Rodent of Unusual Size <Ke...@Golux.Com>]

rbb@covalent.net wrote:
> 
> > 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.

Um, no, you don't get to decide that.  Nobody does.

> 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.

This is not a place where silence gives assent.

> 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.

Yes, it is.  The proper response is to post a correction to the
design, not patches to the code.

> 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.

Bzzzt.  Sorry, no-one is immune to roadblocks, no matter how
irksome they may be.

Can you please post the message IDs of these multiple requests
for clarification you made?  I can't find them..
-- 
#ken    P-)}

Ken Coar                    <http://Golux.Com/coar/>
Apache Software Foundation  <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed"   <http://ApacheUnleashed.Com/>