Commit report for master branch

[Arran Cudbard-Bell]

On 10 Apr 2013, at 11:43, Brian Candler <B.Candler at pobox.com> wrote:

> On Wed, Apr 10, 2013 at 10:00:07AM -0400, Alan DeKok wrote:
>>> It's just that %{exec:...} and %{redis:...} expect to get a single un-xlat'd
>>> string, which they split on space, and then xlat the parts individually.
>> 
>>  Yes.  That can be fixed with simple changes.
>> 
>>  a) the module supplies an "escape" function which escapes spaces
>> 
>>  b) the "split on spaces" code converts escaped characters to the
>> non-escaped version... but doesn't split on escaped spaces
> 
> Like this suggestion? :-)
> http://lists.freeradius.org/pipermail/freeradius-devel/2012-October/007207.html
> 
>>  i.e. the "files" module should parse the xlat expansion once, and save
>> the parsed result.  It can then be interpreted dynamically multiple times.
> 
> Makes sense - like regcomp. (And of course, "files" could also precompile
> the RHS of regexp match operators)

No. Not unless the regexp library supports compiled, parameterised expressions.
If the files parser doesn't currently support nested expansions within the expression,
it will once it calls the new tokenizer.

For things like SQL however, it should be possible to precompile the statements
and you may get a small performance gain doing that.

This would be one advantage of having an xlat specific tokenizer callback. 
It also means that the code that parses attribute references can be moved out
of the tokenizer, it really doesn't belong there.

Conflating xlat functions and attributes makes the code harder to understand, 
there should be one common xlat attribute-ref function, (wrapped and registered 
a bunch of times for the different lists) to retrieve attribute values.

Once nested VPs are done, then there should be a single xlat function to expand all
attribute references.

-Arran