Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Thu, 1 Mar 2001 14:01:07 -0800
From: Greg Stein <gstein@lyra.org>
To: new-httpd@apache.org
Subject: Re: [VOTE]  ap_r* model.
Message-ID: <20010301140107.A2297@lyra.org>
Mail-Followup-To: new-httpd@apache.org
References: <3A9E9295.ACD750C8@algroup.co.uk>
 <Pine.LNX.4.30.0103011034160.14132-100000@koj>
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.30.0103011034160.14132-100000@koj>;
 from rbb@covalent.net on Thu, Mar 01, 2001 at 10:59:45AM -0800

On Thu, Mar 01, 2001 at 10:59:45AM -0800, rbb@covalent.net wrote:
> On Thu, 1 Mar 2001, Ben Laurie wrote:
>...
> > I'd like to request the brief synopsis. Although I did read the mails at
> > the time, I ran out of storage capacity to keep them in my head. Sorry!
> 
> Not a problem.  People, keep me honest.  If I miss something important,
> let me know.
> 
> ap_r* macros:
> 
> advantages:
> 	The problem with ap_r* is that they don't buffer data.  We have
> already solved this problem for ap_f*, so this takes advantage of that by
> using the ap_f* calls in ap_r*.
> 
> disadvantage:
> 	People need to use r->bb in their handler, or the data may get out
> of synch.  This is only an issue for people who want to use both ap_r*
> functions and make their own buckets and their own brigade.  So, if they
> want to create their own buckets, and add them to r->bb, that will work
> fine, but if they want to use ap_r*, and they have their own brigade, bb,
> they will have ordering issues.

In ADDITION: There is a coupling across subsystems introduced by the r->bb
mechanism. As a result, they will have ordering issues unless they *also*
pay attention to what other pieces are doing.

> OLD_WRITE:
> 
> advantages:
> 	The order is always correct.  This is a filter that sits just
> under the handler, so as long as the filter is there, the order is
> correct.
> 
> disadvantages:
> 	This is a special filter, that solves the buffering problem in a
> way completely unrelated to ap_f*.  This means that we have to maintain
> two independant solutions.

Untrue. I have said MANY TIMES that the OLD_WRITE will also use ap_f*. The
current implementation predates ap_f*.

> 	If a filter is added in between the handler and the OLD_WRITE
> filter, then the performance improvement disappears.

While true, it is not a realistic scenario. As I've stated before, the
OLD_WRITE filter should use a filter type such as:

  #define AP_FTYPE_INTERNAL 0 /* reserved for Apache internal filters */

Thus, nobody is/should be using that filter type, and no filter will precede
the OLD_WRITE filter.

> Both solutions have documentation issues, one we have to document r->bb,
> one requires documenting the filter ordering issue.

The #define above is sufficient documentation. People will be using the
other types of filters. At worst, a couple lines in the documentation about
how to decide on your filter type, and therefore the ordering, should be
sufficient. Invariably, developers will simply copy/paste somebody using
AP_FTYPE_CONTENT and never both with reordering. If they do wonder about it
and read the doc, then they'll readily learn the issue. They'll certainly
avoid using anything such as AP_FTYPE_INTERNAL.

With the r->bb system, we have to explicitly document the problem and
somehow get people to read about it. Where do we put that and how do we
bring it to their attention? What will make them even consider that a
problem may exist, and they need to find the answer?

Cheers,
-g

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