httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: Dynamic configuration for the hackathon?
Date Wed, 26 Mar 2008 17:14:31 GMT
On Wed, 26 Mar 2008 12:42:51 -0400
"Akins, Brian" <Brian.Akins@turner.com> wrote:

> On 3/26/08 10:31 AM, "Nick Kew" <nick@webthing.com> wrote:
> 
> > Straightforward: conditions on headers, method (obsoletes <Limit>),
> > request line, env, CGI vars.  With the option to disable conditional
> > stuff for speed. 
> 
> In mod_include, we parse into a tree on every request.  For the
> configuration, we should probably just parse it at startup and "run"
> it on every request.

Indeed - hence the parse/eval separation in the proposed API.

> Also, currently, ap_expr is string specific, it would be nice if this
> was provider based. Not sure of the exact interface, but it would be
> extendable for other types of comparisons, for example.

Well, we always start from a string.  Later when it's tokenised
we can, and indeed do, dispatch to a provider (in mod_include's
case, functions called "handle_foo" for keyword foo).

> typedef struct {
>    apr_status_t (*init_expr)(apr_pool_t *p, const char *lvalue, const
> char *rvalue, int expr, void**data);
>     apr_status_t (*eval_expr)(reuqest_rec *r, void *data);
> } ap_expr_provider_t;

That's no use at top level, because

> So this expresssion, at startup:
> 
> <If Remote_IP =~ 10.189.>
> ...
> </endif>
> 
> Would call the provider registered for "Remote_IP" as:

we have to parse a string before we have Remote_IP.
Once we have that, sure, our evaluation function can dispatch
to the Remote_IP handler.

You seem to be looking a little further than my proposal went.
Which is kind-of why it would be good to hackathonise this:-)

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Mime
View raw message