On 03/14/2007 09:14 PM, Jim Jagielski wrote: > As a rough proof of concept, I refactored the design,
Ahh, and I was wondering myself why I could not find Joe's concerns. I read your refactored code :-). > allowing for the pattern matching and substitution to be > done as soon as we have a "line". Also is some > rough ability to pass the data to the next filter > after we get more than ~AP_MIN_BYTES_TO_WRITE bytes. Sounds good, but do we need to do our own buffering here? Shouldn't we leave this work to the filters down in the chain? They also know how to handle flush buckets in this case. Which brings up an interesting question: What do we do if there is a flush bucket in the middle of a "line"? Flush immediately and risk an unprocessed line or wait for the line break and flush after this line (the second option seems to be more sane to me). > Doesn't alleviate all the problems, but it allows > for us to pass data quicker (we still have the issue > where we need to fully read in the bb though...) But from a first glance this approach has only a memory consumption proportional to the longest line. And I am not sure how you want to avoid reading the whole bb if you want to modify the content. IMHO you can only avoid to have the *whole* content in memory at a certain point of time. > It's rough but passes superficial testing... > > More work needs to be done, but more people could > work on it if I just commit to trunk :) And then it would be easy to track the changes :-) Regards Rüdiger
