On Mon, 26 Nov 2007 16:25:54 +0200 (SAST) "Graham Leggett" <[EMAIL PROTECTED]> wrote:
> On Mon, November 26, 2007 4:18 pm, Nick Kew wrote: > > > mod_include has an expression parser (parse_expr at line 1125 > > in /trunk/). Many other modules implement simpler parsers for > > a range of purposes. > > > > It seems to me we could potentially benefit from a general- > > purpose expression parser, and I'm wondering about extracting > > mod_include's parse_expr as ap_parse_expr, maybe in util.c. > > The job looks like mostly one of removing the include_ctx > > and substituting request_rec, or maybe even pool and a void*. > > > > Does that make sense? Thoughts? > > It makes sense. > > I think a worthwhile exercise is to go through the code and identify > possibly duplicated code, or code with general application to the > server at large that could be used by other modules, and make this > code common. I've extracted the expression parser from mod_include into an ap_expr.c file. It was surprisingly straightforward, and loses none of the functionality of mod_include[1]. The API now includes a string parser function, used where mod_include uses ap_ssi_parse_string. I'm happy with that. However, to avoid losing any mod_include functionality, we also have to pass accessenable as an argument, which is ugly. I think it would be better to drop accessenable (and the consequent subrequest stuff) from the parser. Doing that will leave "-A filename" as part of what's passed to the string parser function, so mod_include should be able to implement access checking there instead (though I haven't thought it through). Next step is to expose a bit more of the API, so that parsing to a tree and evaluating the tree are separate functions, for modules that might want to customise further. [1] Some of the debug stuff is NOTIMPL. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
