Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Sun, 21 Jan 2001 21:26:27 -0800
From: Greg Stein <gstein@lyra.org>
To: new-httpd@apache.org
Subject: Re: Apache 2.0 beta STATUS
Message-ID: <20010121212627.V704@lyra.org>
Mail-Followup-To: new-httpd@apache.org
References: <Pine.LNX.4.21.0101202305160.17536-100000@koj>
 <05ce01c08388$9d4157b0$95c0b0d0@roweclan.net>
 <071f01c08427$8f53aaf0$95c0b0d0@roweclan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <071f01c08427$8f53aaf0$95c0b0d0@roweclan.net>;
 from wrowe@rowe-clan.net on Sun, Jan 21, 2001 at 09:58:20PM -0600

On Sun, Jan 21, 2001 at 09:58:20PM -0600, William A. Rowe, Jr. wrote:
>...
> Filtered (gstein) carries the risk it can be bumped from the filter stack
> by some very mean spirited filter that is VERY_VERY_FIRST (unlikely), but
> applies only to Apache 2.0, and appears stable.

This is a mischaracterization. There is no risk. If somebody sneaks in
front, then the server operates quite fine. Completely robust.

You also did not mention that my patch allows free mixing of ap_r* and
ap_pass_brigade(). There is no possible way for output to be misordered.
Ryan's patch does *not* have that feature, and I pointed that out a *long*
time ago. That was the reason why I veto'd Victor's patch.

I consider mixing of the APIs critical. There is just no simple way to
ensure that output will never be mixed. Consider the handler which uses
ap_r* and then starts a subrequest which uses brigades, which returns to the
handler to use more ap_r* functions. Are we seriously going to start
sprinking order-synchronization calls throughout Apache to ensure that
everything is ordered properly? No. We will invariably miss some. How about
that third party DAV module that uses some output functions from mod_dav?
Which module is in charge of ensuring that the order remains synchronized?
Why should they have to care? (given that I've demonstrated they don't have
to care -- mixing APIs freely is quite possible and quite efficient)

>...
> Based on requirements alone, I'm +1 on the latter patch.  I believe it is

Whose requirements? We're trying to fix Apache, not APR. And we're trying to
provide a way for people to continue to use ap_r* without suffering a
penalty. And we're trying to provide a way that they can transition to a
better API for some of the critical parts.

For example, I would think it would be great for a handler to ap_rputs() a
couple header strings, call a few output functions which use ap_r*, and then
call some other doo-dad that puts together a complex brigade using custom
buckets. Mixing of the APIs is quite important.

[ the above scenario isn't that difficult to imagine: I have been thinking
  about how mod_dav plugins can provide some custom output. The obvious
  mechanism is to let them use brigades/buckets in some way. But the
  wrapping output structures are still easiest to use ap_r* ]

>...
> such nonesense.  The later seems more stable, in that the module author
> determines the stability.

Euh... why not just start with stable in the first place. You can't get
messed up output with my patch. No matter what you do.

>...
> As I say, I'm for the module author controlling the unknowns with as little
> possible chance for interference from 'invisible forces'.

The invisible forces in this case is the requirements imposed by forcing a
module author and even the core Apache code to have to synchronize between
two totally different output mechanisms. Each coder must be aware of all the
other bits of code which could potentially produce output. Even worse, they
need to know *how* that other code did it. Not just "did they?" but "how?".
That kind of invisible coupling across the code base is a recipe for bugs.
Insert a sync call here, insert one there. Oops, we forgot to sync the two
mechanism over there, too. Oy! :-)

Cheers,
-g

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