On Thu, May 09, 2002 at 05:18:42PM -0700, Aaron Bannert wrote: > Let me be more precise. I'm not saying that we shouldn't use > brigades. What I'm saying is we shouldn't be dealing with specific types > of data at this level. Right now, by requiring a filter to request > "bytes" or "lines", we are seriously constraining the performance of > the filters. A filter should only inspect the types of the buckets it > retrieves and then move on. The bytes should only come in to play once > we have actually retrieved a bucket of a certain type that we are able > to process.
I really think you're talking about a push-based filter system. However, it seems that there was a conscious decision to use pull for input-filters. I wasn't around when that discussion was made. I'd like to hear the rationale for using pull for input filters. > HEADER > HEADER > HEADER > DATA (extra data read past headers) > SOCKET > EOS Sending metadata down is a big change. Again, I *think* this was discussed before, but was determined that this wasn't the right way. I think we're going down a path that was discussed before. (As Manoj kidded me last night, you and I seem to retrace old discussions coming to the same conclusions Ryan and he did.) So, I think we need some of the old people to tell us why we aren't doing this. (If we do this for input filters, I think we need to do the same for output filters.) > around in my head for a long time. When they become clear enough I will > write up a more formal and concise proposal on how I think the future > filter system should work (possible for 2.1 or beyond). I think the > apr-serf project is a perfect place to play with some of these ideas. I > would appreciate any constructive comments to the above. ] I'm not sure I'm happy that so early in the 2.0 series that we're already concerned about the input filtering. I don't think it's ever been "right" - probably because it was ignored for so long. It's showing now. If this prevents people from writing good input filters, I think we need to fix this sooner rather than later. -- justin
