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 Thu, 01 Mar 2001 21:50:58 GMT
On Thu, Mar 01, 2001 at 11:35:59AM -0800, rbb@covalent.net wrote:
> On Thu, 1 Mar 2001, Rodent of Unusual Size wrote:
> 
> > 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?
> 
> No.  Either way, the old ap_r* calls always work.  The module author only
> needs to re-learn anything if they WANT to use the direct bucket calls.
> If they stick with just ap_r*, there is nothing new in either model.


That is not a complete accurate description of the problems with the macros.

Let's say the module author sticks with ap_r*. Now, if a utility function
generates a brigade and delivers it, then they will have an ordering
problem.

The problem is that r->bb introduces *coupling* in the server. All content
generation needs to be aware of how the other pieces are being generated.
They all need to use ap_r* and r->bb, or they all need to use their own
buckets. You cannot even let *ONE* subsystem vary.

Thus, all subsystems must describe to all callers what implementation they
choose to use. That flat out sucks.

Cheers,
-g

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

Mime
View raw message