httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Re: what are the issues? (was: Re: Patch review: ...)
Date Fri, 30 Jun 2000 14:33:14 GMT

Roy's example of the need to sum up meta data (content length, mod time)
is one aspect of why I think, as he says, and ADT is a good thing in the
filter design.

I wish we were doing more design on this thing.  I wish I had more time.

There are three ADT I perceive in the design space:
 1. The filter elements (they need a place to store thier microtasking state).
 2. The buckets (we need a chunky spread, and a place to sum up meta data).
 3. Read/Write heads for the individual filter elements.
    (we need a vprintf, et. al. and we need an error protocol).

The holly grail is to find a way to get a bicycle that can evolve into
earth mover.  What makes that hard is that the bicycle needs to start
out with certain organs.  These appear to me to include:

All of this heat is probably for the best.  All that Apache does is
I/O so this is important.  Boy is it emotionally draining.

 - ben

"Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU> writes:
> That would not be a solution. The purpose of passing a list of buckets around
> is to linearize the call stack for the frequent case of filtered content
> splitting one large bucket into separate buckets with filtered results
> interspersed in between.  The effect is that a filter chain can frequently
> process an entire message in one pass down the chain, which enables the
> stream end to send the entire response in one go, which also allows it
> to do interesting things like provide a content length by summing the
> data length of all the buckets' data, and set a last-modified time
> by picking the most recent time from a set of static file buckets.
> 
> I think it would help if we stopped using artificial examples.  Let's
> try something simple:
> 
>        socket <-- http <-- add_footer <-- add_header <-- send_file
> 
> send_file calls its filter with an ap_file_t bucket and End-of-Stream (EOS)
> in the bucket list.  add_header sets a flag, prepends another ap_file_t
> bucket to the list and sends the list to its filter.  add_footer looks
> at the list, finds the EOS, inserts another ap_file_t bucket in
> front of the EOS, and sends the list on to its filter.  http walks through
> the list picking up the (cached) stat values, notes the EOS and seeing
> that its own flag for headers_sent is false, sets the cumulative metadata
> and sends the header fields, followed by three calls to the kernel to
> send out the three files using whatever mechanism is most efficient.

Mime
View raw message