httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [VOTE] ap_r* model.
Date Fri, 02 Mar 2001 09:01:20 GMT
On Thu, Mar 01, 2001 at 02:51:47PM -0600, William A. Rowe, Jr. wrote:
> From: "Rodent of Unusual Size" <Ken.Coar@Golux.Com>
> Sent: Thursday, March 01, 2001 1:23 PM
> 
> 
> > 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.

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.

Maybe I'm dumping a bunch of DAV:href elements to the output stream as part
of the DAV:compare-report that I'm generating. So I call over to a utility
function in mod_dav proper so that it can convert the URL into an absolute
URL (from a relative form), then encode the URL from the system character
set into a set of octets, then do the URL %-encoding, then wrap it all up in
a nice <D:href> element, then drop it down the pipe. Umm... What output
mechanism did it use? I *have* to know to prevent ordering problems.

In all of these examples, the caller must be aware of implementation details
of the utility function. That is called "coupling", and it creates very
brittle systems that can easily be broken.

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

Both of those functions are needed to patch up problems. The problem is with
the API, and the system can't do anything to fix it for you.


On the contrary, OLD_WRITE just does its work and keeps it all flowing
smoothly. No need to be concerned. If you want to *deliberately* insert a
filter before it, then it is your damn fault. It isn't "just going to
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.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message