On Wed, 14 Mar 2007 14:32:13 +0000 Joe Orton <[EMAIL PROTECTED]> wrote:
> 1) the filtering logic is broken and will consume RAM proportional to > response size. I must've missed that when I looked. I thought it used the same logic as mod_line_edit, which is very careful about that. Oh, I guess you mean the copying to get a null-terminated string when applying a regexp? And I see it's repeated for every regexp (ouch)! mod_line_edit uses a local pool which is cleared at the end of each brigade, and avoids multiple copies of the same buffer. > 2) 200-line functions are hard to read :) mod_line_edit does the same there, but that's definitely being split (not least so that the actual search-and-replace function can be re-used in a companion input filter). And given that it's unusually well-commented and half of it features as example code in my book, I don't think it's hard to read:-) > Nick, are you actually planning to submit mod_line_edit for inclusion > in the tree? The subject hasn't arisen until this thread (which caught me rather off-balance), but I'll be happy to include it if there's demand. As I hinted, there are some enhancements in the pipeline. If it goes in to trunk, a roadmap would probably be in order. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
