On Thu, Mar 01, 2001 at 11:35:59AM -0800, [EMAIL PROTECTED] 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/
