Author: Brian Candler Date: To: Tony Finch CC: exim-users Subject: Re: languages again,
was Re: [exim] relative 'expense' of Exiscan/SpamAssassin vs.
local_scanfor simple header/body triggers?
On Mon, Sep 19, 2005 at 11:28:50AM +0100, Tony Finch wrote: > Actually I answered that question extremely badly the first time round, so
> I'll have another go. This isn't a matter of personal preference: there
> is plenty of engineering experience that we can draw on.
I am guilty of woolly thinking on this too. I think what I was trying to say
was, "perhaps Exim could borrow some syntax from Ruby"? I think we can agree
that we wouldn't want /usr/exim/configure looking like Perl :-)
> The EDSL configuration should preserve this hiding of complexity, which
> means that configuration keywords like drop/deny/defer/accept have to be
> able to affect the control flow without requiring boilerplate from the
> user. This is even more important in the routers, where instead of
> dropping back into Exim's core, you usually want to skip to the next
> router. > It's better to make the whole chain of routers a single routine
> (rather than one per router) because then the postmaster can code
> complicated routing decisions beyond the usual sequencing, but this in
> turn makes difficult demands of the host language.
Although if a single router could have arbitary logic in it, then for
complex applications you could just have a single router (or put this single
router in the appropriate place in the sequence of routers)
I've certainly missed the ability to jump forward to a particular router,
having to code each of the intervening routers with a test to say "don't do
this if the previous router set something magic in $address_data"
> However both these languages suffer from lack of static checking (in the
> case of Tcl even at the level of syntax) which imposes a burden of testing
> on the postmaster which in an ideal world would be performed
> automatically.
This is a feature of exim already. You can written a complex expression,
start Exim happily, and only when the expression is triggered do you get a
4xx "defer" and an error about mismatched braces. Arguably then it's up to
the postmaster to run a test suite against her configuration to exercise it
properly (which you can build yourself using -bhc, although having that
framework provided would be nice)
Exim *could* pre-parse expressions which it knows may be expanded at
runtime, other than ${expand:...} of course. The other checking it could do
is whether $var exists or not, given a master list of variables which might
exist at this point in the configuration. But even then, it's very easy to
write syntactically valid expressions which don't actually do what you want,
especially with regexp quoting around. I often have to test \. versus \\.
versus \\\\. to see which is right.
I don't think static type checking makes much sense in the context of string
expansions, where everything is a string. However it might make sense if you
were to handle things like domainlists and hostlists as native objects in
this language.
Perhaps before looking for a solution, it makes sense to at least think
about where the problems lie. For me the biggest one is writing expressions
nested more than 2 deep in the string expansion language. (IIRR, this is why
the ACL language came about; the string expansion language could have
handled ACLs perfectly well, it's just they would have been impossible to
write :-)
The other problem for me is too many quoting rules: unquoted strings, quoted
strings, list separators, regexps, database lookups...
