httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: [VOTE] ap_r* model.
Date Thu, 01 Mar 2001 22:17:34 GMT
On Thu, 1 Mar 2001, Greg Stein wrote:

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

This doesn't exist at all if the sub-systems use ap_r.  At least not
anymore than it does for the OLD_WRITE filter.

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

Which will still be implemented as a filter.  While the buffering itself
may use ap_f* under the covers, the maintenance of the actual filter is
still an issue.

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

I am thoroughly against this proliferation of filter types, and have been
since the beginning.  What happens when Apache needs something to go
between the OLD_WRITE filter, and another filter?  We create another
filter type?

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


Mime
View raw message