[EMAIL PROTECTED] wrote:
>
> 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.
Woah! So you are saying we _can't use brigades_ in subsystems with your
solution? That's completely unacceptable.
My vote is for Greg's scheme, in that case.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
ApacheCon 2001! http://ApacheCon.com/
