httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Apache 2.0 beta STATUS
Date Mon, 22 Jan 2001 03:58:20 GMT
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Sent: Sunday, January 21, 2001 3:00 AM


> From: <rbb@covalent.net>
> Sent: Sunday, January 21, 2001 1:12 AM
> 
> > 2)  We have 1 patch that must be committed before we go beta.  That is the
> > ap_r* performance patch.  There are two patches that have been submitted,
> > and I asked for a vote to end tomorrow morning.  Unfortunately, nobody has
> > voted for either patch at this point.  I am asking that people review
> > these patches, and vote for one of them.  I had planned to commit one of
> > the patches tomorrow afternoon.  I will not commit either patch until at
> > least three people (other than Greg and I) vote for a patch.  Please
> > review them and ask any questions you might have.
> 
> We have as many patches as it takes to make apache.org stable.  Yes, we
> need to choose a patch for the ap_r* fns - I'm leaning twords the apr
> implementation over the filter implementation, for the reason that we
> have a more thorough bucket/brigade/buffering solution within apr that
> isn't restricted to the apache solution.  If their is a technical flaw
> with either patch, someone please point it out.

Ok... my understanding (with gstein's and rbb's latest updated patches);

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.

Buffered apr (rbb) requires an additional call to transition between the
buffered api and buckets api.  It appears stable.

Based on requirements alone, I'm +1 on the latter patch.  I believe it is
better to tell the author "Add this call and you will be safe", rather than
chase obsure module authoring bugs that flushed the filter list or other
such nonesense.  The later seems more stable, in that the module author
determines the stability.

But now, we have doug's patch.  Without line-by-line pulling me out of my
little filesystem world just now, would anyone care to comment on the
merits of Doug's v.s. rbb's v.s. gstein's patches?  Maybe the six paragraph
executive summary :-?

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

Bill


Mime
View raw message