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: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 03 Oct 2000 00:07:25 GMT
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Monday, October 02, 2000 6:46 PM
> 
> I disagree completely.  If mod_random is written to re-arrange buckets,
> then it is broken.  It is completely impossible to determine how a handler
> will arrange the content in a brigade.  

Still disagree here.  Another fine example.  Let us consider performance from
this perspective... we have a filter that takes an inordinate amount of cpu
per iteration, and no significant time per byte.  Bill's filter, in this case,
would be a great benefit to drop the number of iterations through such a filter.
Excuse me for not being able to invent a specific example.

> I entirely expect to re-write mod_autoindex to use a single brigade to 
> pass data down, at far fewer buckets than it currently uses.  The only 
> reason I haven't done so already is that I have had bigger fish to fry 
> and very little time.

That's a given, and +++1's to you if you are the first to get to it :-)

> Filters can not be written to expect data in any particular
> format.  Filters have to accept buckets of data, and they have to work
> with the data, not the buckets.  Otherwise the result of those filters
> will be unpredictable.

No... filters cannot expect data to be in a particular format, but need
to be able to identify the data and warp it appropriately.  Perhaps my
long term vision of filters is broader than some folks, but I've always
pictured a filter picking up on headers_out and deciding that they are
something else, and the filter is the means to make that something else.

> There are only two reasons IMHO to buffer above the core filter:
> 
> 1)  The ap_r* functions should do some buffering, so that we make as few
> trips down the stack as possible.  This is an optimization and should wait
> to be done.  I expect there will need to be some logic to ensure that we
> don't try to buffer too much or at inappropriate times.

ap_r* is going away, correct?  It's legacy, and I'm not too concerned.
 
> 2)  The filter requires it.  This is something like our favorite
> mod_content_length example, where the filter requires that it has all of
> the data before it passes down the stack.

And that's what I'm suggesting.  If we can create a universal buffering
filter to accomodate such needs, let's not expect every author to reinvent.

Mime
View raw message