On Thu, Aug 29, 2002 at 01:18:59AM -0700, Justin Erenkrantz wrote:
> On Wed, Aug 28, 2002 at 06:26:16PM -0700, Aaron Bannert wrote:
> > 1) Let's get away from the notion of Push and Pull, and go to the idea
> > where the app drives the filter chain, and each filter is given
> > control of a piece of data for a short period of time.
>
> Can you give an example of how a client would read and write
> data? (Feel free to ignore the filters part.)
>
> To give you an idea where I'm coming from:
>
> A push-model would be driven by a poll() loop. As data is available
> on the sockets, the socket would be read and the data would be
> pushed into the filter chain.
>
> A pull-model, when invoked, would first check to see if there is any
> data in the 'spillage' (i.e. left over from last read). If there is
> enough to return, it would do so. If there isn't, then it would call
> poll() and wait for something. Once data is available, it reads from
> the socket and pushes the data into the filter chain. Then, as data
> comes out of the filter chain, it is returned to the client.
[I'll respond to this first, and then follow up to other points/questions
in later messages.]
The key to keep in mind with my model is it is never a complete system.
It is totally open-ended in the sense that when we have new ways of
transfering/muting data we can add new filters at the appropriate
level, or if a layer is missing we can create a new one.
So, an example how a client would read and write data to the wire:
Let's say that all the client-side logic is contained within one
magic filter, that produces REQUEST_HEADERS, REQUEST_BODY,
and REQUEST_TRAILERS.
SOURCE --> SINK
SOURCE --> CLIENT_LOGIC_HANDWAVING --> REQUEST_WRITER --> SINK
So, the only extra piece is the RESPONSE_WRITER, which takes
all three types produced by the C_L_H and writes those to the
socket.
Let's say you wanted to then add support for chunked-encoding.
Since chunked-encoding can be thought of as a layer below the
simple {headers, body, trailers} model, we would invent some
new types and filters that could consume headers and bodies,
add the T-E: chunked header, and then produce REQUEST_HEADERS
and REQUEST_CHUNKs. The REQUEST_WRITER would then be modified
to accept the new REQUEST_CHUNK type.
There is a whole bunch of handwaving here, and I realize that.
I think the best way to continue on this path is to try to lay
out various example scenarios, and then try to actually code
some of this up. We have some fairly large pieces that could
be designed and written.
> Yea, linear filters seem a bit antiquated, but how one filter
> could then branch its data to two filters doesn't seem like it
> could work. So, at its essence, it seems it'd have to still be
> linear. So, do you have a use-case where the data isn't linear?
I'm mostly imagining something like "If you see a SSI chunk, give it
to me, otherwise just pass the inbetween data to the next guy and
pass me up [as an optimization]".
I'll continue in another post...
-aaron
