On Thu, 1 Mar 2001, Greg Stein wrote:
> On Thu, Mar 01, 2001 at 10:59:45AM -0800, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
