Brian Candler wrote:
Ah, suddenly I see where we're going. If it had used a more Perl-PHP-like $ I think I would have gotten it straight away.
if ($Framed-IP-Address > 192.168.0.0/24) { .. }
Yeah. Except $ is already used for config-file expansions.
Aside: with explicit variable reference like this, I think the update {...} syntax might become redundant. e.g. you could just have
$Tmp-IP-0 := $Framed-IP-Address
Hmm... that's a good point. I'll look into that.
An explicit tag could also allow the expression language to expand to cover eval, although minuses would have to be space-delimited:
if ($Event-Timestamp - $Acct-Session-Time < $Tmp-Integer-0) { ... }
Yes, probably. But that's lower on the priority list.
Yes I see, that's another way it could disambiguate attribute names from literals. It's a bit odd, if something which you know to be an enumeration constant representing an integer, has to be quoted as a string.
Not really. PPP isn't a valid attribute name. So it must be an enumerated value.
Having said that, things like
Service-Type := "%{sql...}"
are presumably still going to be allowed, so string->constant lookups can take place dynamically.
Yes.
So thinking aloud, the rules might be:
- a quoted string is a string
- an unquoted bareword which parses as an integer or an IP address has that type
That's hard. There can be overlaps between the syntax of the various types. It's easier to just demand that the types be explicit. I think the "getting rid of update sections" above is a good reason to keep using "&" for attribute references. In that case, the rules are pretty simple. - & is an attribute reference (except it can be omitted on the LHS for backwards compatibility) - everything else is type-specific - strings MUST be quoted - other types MUST NOT use single quotes - other types MAY use double quotes / back-ticks for later expansion - bare words for other types MUST be parsable as the type e.g. in v2, "Framed-IP-Address < 127.0.0.1" was stored as a string, and parsed at run-time. Right now, it's split into a LHS (attribute reference), operator, and RHS (string). It *should* parse && save the RHS, so that it doesn't have to re-parse it at run-time. That's relatively easy to do in the new framework. Catching errors on startup is preferable to catching them at run-time. Alan DeKok.