Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Tue, 29 Aug 2000 20:18:55 -0700
From: Greg Stein <gstein@lyra.org>
To: new-httpd@apache.org
Subject: Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
 util_filter.c
Message-ID: <20000829201855.J22160@lyra.org>
Mail-Followup-To: new-httpd@apache.org
References: <20000830010916.83733.qmail@locus.apache.org>
 <Pine.LNX.4.21.0008291904400.13962-100000@koj.sfo.covalent.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <Pine.LNX.4.21.0008291904400.13962-100000@koj.sfo.covalent.net>;
 from rbb@covalent.net on Tue, Aug 29, 2000 at 07:09:59PM -0700

On Tue, Aug 29, 2000 at 07:09:59PM -0700, rbb@covalent.net wrote:
> On 30 Aug 2000 gstein@locus.apache.org wrote:
> > gstein      00/08/29 18:09:15
> > 
> >   Modified:    src/include util_filter.h
> >                src/main http_core.c http_protocol.c util_filter.c
> >   Log:
> >   reversing the latest commit; it was vetoed a while back.
> 
> As outlined in my last mail, this is BS.  The only technical reason for
> the veto is that it goes against the design we had, and that it makes the
> insert_filters hook backwards.

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?

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.

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.

We need justifications for our vetoes, and they should be based on some
reasoning which is suitably specific enough that it can be addressed. When
Ken was saying that we need a technical reason, I interpreted that as
"please provide the detailed reasons such that I can address them in my
patch." Ambiguity and non-specificity was the problem at the time.

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.

>...
> I have given strong technical
> arguments for why this needs to be a stack,

>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 a stack? Nope.

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.

>...
> The current design has us inserting a new filter type everytime we find
> one filter that must be added before another filter.  This is not a viable
> way to design code that has to be used into the future.

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, the fixed number of classes *might* be an issue. I'll concede that at
some unknown future point in time, somebody out there might come up with a
filter that they just *have* to have different handling on. But tossing out
the grouping mechanism isn't the right solution -- you would then need to
provide some kind of hook at the right point in the code so they could
prepend their filters at the correct moment. I'll take a set of enums
(possibly spaced apart so there are "cracks" that people can use) over a set
of specific code points scattered throughout the core.

Cheers,
-g

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