On Tue, Oct 16, 2001 at 08:51:38AM -0700, Aaron Bannert wrote: >... > Yes. These seem like some of the same issues that have come up lately on > httpd. I think the problem in semantics here comes from the fact that all > filters are being forced to define their data requirements in terms of > bytes, when that isn't really what unit of data they deal with internally. > A Dechunk filter only cares about chunks and chunk tags, for example.
A stream is only bytes. We can't really define the interfaces between the filters in any other way. > ... > > > Also, since some filters may be provided > > > by our library (chunk, ssl, basic auth, various header manipulations, etc) > > > and some will be provided by the application (flood will have a > > > content-length > > > verification filter, a webservices thingy could render some xml, etc), and > > > > Yes, although auth isn't really a filter. There is a lot of high-level > > processing related to auth (think about failing auth, asking the app for > > auth data, then re-submitting the request; a filter can't do that). > > I don't follow you. If a filter detects that auth fails, it passes a poison > pill down the filter chain. I don't know what you mean by asking the app > for auth data, the app should have inserted a filter to do this, no? When authentication fails, the application needs to resend the request with new auth info. So... *something* needs to ask for auth data, and something needs to resend. My point was that those activities don't belong within the filter chain, but at the app level. Thus, your listig of "basic auth" as a possible filter doesn't make sense -- a filter can't generate a new request since it is really only about processing a response for an existing request/response. Yes, it could be possible to replace the response brigade with an "error" brigade detailing the auth failure. In that sense, you could do a small bit of auth handling as a filter, but really: it is just looking at a single header. > > > since it seems that most of the power of our library will be in the > > > filters, > > > I don't see why the application will care if it's push or pull. > > > > The app will have data pushed at it, or the app will pull data from the > > library. Transparent to the app, some filters will execute in there. > > When I consider the app, I'm picturing it as a control mechanism for > this filter chain, where it has already inserted strategic filters of > its own into the chain and then triggered a push or pull on the chain. > I don't see data spilling out the end of the chain, but I may not be > seeing the whole picture yet. If the network layer pushes data into the response chain, then the terminus of that chain could perform all handling / consumption of the response. If the application *pulls* the response, then data does "fall out" of the chain. For a push model, I would agree with you: the app just sets up the chains, shoves requests down the request chain, and then spins up the network processing loop (to wait for an process responses). On a separate note: my comment above made me think that "request chain" and "response chain" might be better than "input chain" or "output chain". They describe what is going through them much better. >... > I have some thoughts about this in the design drifting on the flotsam in > my head, but the details are not yet clear. I think the main things we > have here are: 1) the app controls how filters are ordered in the chain, > 2) we can create utilities that the app can use to order the chain (these > utils can be complex enough so as to completely hide the ordering), 3) > I completely agree that filters should know nothing about the filters > before or after it in the chain. Agreed. Cheers, -g -- Greg Stein, http://www.lyra.org/
