On Wed, Aug 28, 2002 at 12:08:59PM -0700, Aaron Bannert wrote: > Filter interaction should not think in terms of bytes.
Push-based filters can't think like that. We don't know what the end result is going to be. All we know is that we received something from the socket - we churn it through the filters, and something comes out on the other end. The key is here is all of the filters are push - not pull. A pull is merely a call to special code that triggers the socket to go read and push data down the pipe (if it doesn't have any data in its 'spillage'). Hopefully, something comes out on the other end. Notice the bit at the end where Greg proposes that each socket *read* gets its own independent thread. Now that I think about it, what happens if we do a pull and not enough data is generated to make it through to the end of the filters? Eek. That pull call returns nothing? Specifically to what you were thinking about, I think we could have a HTTP protocol filter that morphs from the bytes to the HTTP-specific entities. However, if we generalize for a second, pull calls must also offer a byte-oriented API to help those filters that need byte-orientation (think SSL). So, it sounds like we need a hybrid approach. An API could be provided that allows saying, "Gimme the entire body" or "Gimme the headers" as well as "Gimme X bytes." In fact, I wonder if we have two types of filter chains. One that has the byte-orientation (for SSL et al - connection-level) and another for the entity-orientation (once the protocol is fixed and determined). The bottom-half is byte-oriented, and the top-half is entity-oriented. -- justin
