httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: [VOTE] ap_r* model.
Date Fri, 02 Mar 2001 15:04:45 GMT

> > > Consider the case of an existing (1.3) module that uses
> > > ap_r*.  The author's goal is to do as little as possible
> > > to make it work under 2.0.  It sounds as though the OLD_WRITE
> > > solution will do this; he can leave all his content-related
> > > calls along, and just upgrade the hooks.  The macro option
> > > requires him to learn about bucket brigades.
> > >
> > > Is that correct?
> >
> > Nak.  ap_r* fn's would create an r->bb for him, and shuttle all of
> > his ap_r* calls into that brigade.
> >
> > Only the _cross-mechansim_ author needs to know that if he _chooses_
> > to create is very own brigade,
> Or an author who chooses to always use ap_r*, but happens to call some
> subsystem or library or whatever which has been converted to the
> more-efficient brigades.
> Ordering errors can affect anybody. A module author would need to know the
> output mechanism used by *all* the things that they might call. An author
> can't settle on a scheme and be safe. He has to know what other people are
> doing, despite any attempt at modularization and encapsulation.

How likely is this, REALLY.  I agree 100% that somebody might use a
subsystem that wants to add to the brigade, no argument there.  Why
wouldn't that sub-system accept a brigade as an argument?  It seems to me
that if I were writing that subsystem, I would probably want it to be
usable in both filters and handlers (if not immediately, then sometime in
the future).  In order for that to happen, the subsystem would need to
accept a brigade as an argument.  I'm not saying that we need to force
people to code that way, I am saying look at the argument, and tell me how
common it really is.

If I have to pass in a brigade to the subsystem, then this whole problem
with subsystems goes away, doesn't it?  The problem with the subsystem you
are talking about, is that it tries to send data to the next filter.  If
it doesn't, then this problem already exists.  In fact, in a subsystem
without the r->bb, the subsystem has NO CHOICE, it MUST use ap_r*, or
create it's own brigade to send down the stack.

> Feel like inserting a formatted time into the output stream? Want to call a
> utility function for that? You better know what it is using.
> Writing an SMTP system and need to dump some MIME headers to the output? You
> better be aware of the output mechanism used by that dump-table-to-output
> function shared with Apache's MIME header output.

Let's take this as an example please.  I see three ways to write this with
the old_write filter.

1)  Pass in a brigade, and allow the subsystem to add to that brigade
2)  Pass in a request_rec, and the subsystem will use ap_r to write to the
next filter
3)  Pass in a request_rec, and the subsystem will use it's own brigade.

Let's ignore option 1, because if we use option 1, then both models can
use it, and all your problems go away.

Option 2 means that they will use ap_r, which works in both cases, just

Option 3 is that the subsystem will use it's own brigade.  Well, that's
just broken, in any model.  What if my handler has a brigade, and it put
data in it, then called to the subsystem.  Whoops data ordering problem.
The problem here is that I would need to flush my brigade before I called
into the subsystem.  That's just the way this stuff works.

> > it isn't in sync with any ap_r* calls
> > he might make, unless he then stuffs it in r->bb (presuming r->bb wasn't
> > created... hmmm, sounds like an ap_set_request_brigade() semantic is in
> > order to be _certain_ that user's don't directly hork up an already
> > created r->bb)
> Yup. You need more than just ap_r*. You also need your setup function you
> mention, and you also need a function to flush r->bb (I've called it
> ap_sync_output in the past) when there is a possibility of flipping between
> the two output models.

Isn't that ap_rflush, which has been in the code forever?

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


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message