Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of jorton@redhat.com designates
 66.187.237.31 as permitted sender)
Date: Thu, 11 Dec 2008 16:05:18 +0000
From: Joe Orton <jorton@redhat.com>
To: dev@httpd.apache.org
Subject: ap_expr.h interface review
Message-ID: <20081211160518.GA25382@redhat.com>
Mail-Followup-To: dev@httpd.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor,
 Berkshire, SL4 1TE, United Kingdom.
  Registered in UK and Wales under Company Registration No. 03798903
  Directors: Michael Cunningham (USA), Brendan Lane (Ireland),
 Matt Parson (USA), Charlie Peters (USA)

typedef enum {
    TOKEN_STRING,
    TOKEN_RE,
    TOKEN_AND,
} token_type_t;
} token_t;
} backref_t;

... all lack namespace-safety.

as do:

typedef const char *(*string_func_t)(request_rec*, const char*);
typedef int (*opt_func_t)(request_rec*, ap_parse_node_t*, string_func_t);

which are also undocumented and lacking parameter names.  What should 
such callbacks do/return?

AP_DECLARE(ap_parse_node_t*) ap_expr_parse(apr_pool_t *pool, const char *expr,
                                           int *was_error);

the "was_error" parameter seems to be redundant with the function 
returning NULL to indicate error?

The grammar of the expression being parsed is undocumented.  (well, I 
could guess that it might happen to match the grammar documented in the 
mod_include docs, but could everybody guess that?)

The purpose of the the *_func_t callbacks is pretty unclear without 
reference to the grammar.

The naming of the "TOKEN_ACCESS" constant seems to be a throwback to the 
use of this API in mod_include?

AP_DECLARE(apr_status_t) ap_expr_init(apr_pool_t *pool);

this is a purely internal interface so needn't be exposed to modules 
AFAICT.

Regards, Joe