On Fri, 2 Mar 2001, Bill Stoddard wrote:
> > > I think I remember gstein writing...
> > >
> > > > happen", but can only happen by a deliberate action of a module author.
> They
> > > > have to take special measures to get themselves in front of OLD_WRITE.
> We
> > > > don't have to take precautions against deliberate troublemakers; there
> are
> > > > too many other ways that a module author can screw things up.
> > >
> > > The problem isn't me as a module author, it is the other guy. My module
> > > may be fine, but what if there is another module that isn't.
> >
> > Here's the upshot.
> >
> > OLD_WRITE filter can be blown away not paying attention to filter ordering.
> >
> > r->bb can be blown away by anyone not paying attention to the request's own
> brigade.
> >
> > Which of these is harder to debug ?!? Harder to document ?!? That's the
> key!
> >
> > [We aren't talking about buckets here guys... the -brigade- is that stream
> that
> > is sent down the filter stack. I have yet to be convinced we need more than
> one
> > per request. As FirstBill and rbb point out, you just keep adding to it.]
> >
> > I see ordering problems as the hardest headache to debug. r->bb misordering
> is
> > fairly straightforward - if you start misordering, the module _author_
> messed up.
> > If you have a filtering problem, the user will have some impact on filter
> ordering.
> > That means they can create a problem. If it's a choice between the module
> author
> > and the end user creating bugs, I'll take the author's bugs any day.
> >
>
> I'll pose the questions that are most important to me... I ship a binary only
> copy of a server based on Apache 2.0. My customer may add their own or third
> party modules to the server. What do they (and the third party module
> authors) need to know to not screw up? I voted for r->bb initially based
> largely on design purity and philosophy but I am still listening to the
> arguments and may switch based on Greg's comments. Which is the most fool
> proof in the common cases? What are the common cases (filter to add a custom
> header? filters to do transcoding?, content generators?).
Here's the thing. If you are in a handler, as long as r->bb is used, then
there is no chance of getting data out of order, and the performance is
good. If you are in a function called from a handler, there are very few
options. 1) A brigade is passed in (the handler should pass r->bb), 2)
no brigade is passed in. In case 2, the function should use ap_r or
r->bb. But, case 2 should never happen. If it does happen, then the
function really isn't all that useful, because it can only EVER be called
from a handler. It also has the disadvantage that the following will
cause ordering problems:
foo = ap_create_brigade(p);
ap_insert_bucket(foo, ap_make_bucket_heap("FOO BAR"));
subsystem(r); /* This sends BAZ to the next filter */
ap_pass_brigade(foo);
In this case, using OLD_WRITE, you will get:
BAZ FOO BAR
With r->bb, just change foo to r->bb, and assume subsystem is written
intelligently, and you get:
FOO BAR BAZ
Which, is what I would expect.
By written intelligently, I would expect that susbsystem either uses r->bb
or ap_r* to write to the network. To make OLD_WRITE work with the above
code, you need to call ap_pass_brigade before calling subsystem.
To make the solution even cleaner, change subsystem the subsystem call to:
subsystem(r->bb);
This will actually work with both models, and we remove any possibility of
having data out of order.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
