Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Thu, 9 May 2002 17:57:16 -0700
From: Justin Erenkrantz <jerenkrantz@apache.org>
To: Aaron Bannert <aaron@clove.org>, dev@httpd.apache.org
Subject: Re: How I Think Filters Should Work
Message-ID: <20020509175716.X24386@apache.org>
Mail-Followup-To: Justin Erenkrantz <jerenkrantz@apache.org>,
	Aaron Bannert <aaron@clove.org>, dev@httpd.apache.org
References: <20020507130906.D14727@clove.org> <20020507131412.O25502@lyra.org>
 <20020507132654.E14727@clove.org> <20020509151957.T24386@apache.org>
 <20020509171842.Y14727@clove.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20020509171842.Y14727@clove.org>;
 from aaron@clove.org on Thu, May 09, 2002 at 05:18:42PM -0700

On Thu, May 09, 2002 at 05:18:42PM -0700, Aaron Bannert wrote:
> Let me be more precise. I'm not saying that we shouldn't use
> brigades. What I'm saying is we shouldn't be dealing with specific types
> of data at this level. Right now, by requiring a filter to request
> "bytes" or "lines", we are seriously constraining the performance of
> the filters. A filter should only inspect the types of the buckets it
> retrieves and then move on. The bytes should only come in to play once
> we have actually retrieved a bucket of a certain type that we are able
> to process.

I really think you're talking about a push-based filter system.
However, it seems that there was a conscious decision to use
pull for input-filters.  I wasn't around when that discussion
was made.  I'd like to hear the rationale for using pull for
input filters.

> HEADER
> HEADER
> HEADER
> DATA (extra data read past headers)
> SOCKET
> EOS

Sending metadata down is a big change.  Again, I *think* this was
discussed before, but was determined that this wasn't the right way.
I think we're going down a path that was discussed before.
(As Manoj kidded me last night, you and I seem to retrace old
discussions coming to the same conclusions Ryan and he did.)
So, I think we need some of the old people to tell us why we
aren't doing this.

(If we do this for input filters, I think we need to do the
same for output filters.)

> around in my head for a long time. When they become clear enough I will
> write up a more formal and concise proposal on how I think the future
> filter system should work (possible for 2.1 or beyond). I think the
> apr-serf project is a perfect place to play with some of these ideas. I
> would appreciate any constructive comments to the above. ]

I'm not sure I'm happy that so early in the 2.0 series that we're
already concerned about the input filtering.  I don't think it's
ever been "right" - probably because it was ignored for so long.
It's showing now.  If this prevents people from writing good
input filters, I think we need to fix this sooner rather than
later.  -- justin