On Wed, 14 Sep 2005, Jonathan Sambrook wrote:
> Any comments are welcome as to whether the idea of multi-line macros is
> generically useful (i.e. will some implementation make it in?) and if
> so, how could this patch could be tidied up, improved or re-implemented.
In the beginning, Exim was modelled on Smail 3, and had only a simple
configuration file with straightforward name=value settings for options.
I kept it simple, because the configuration file is frequently read.
Admittedly, the seeds of complication were already sown by the inclusion
of expansion strings that had a bit more than just variable
substitution; IIRC, lsearch and dbm lookups were there from the start.
Filters were added early on, and the language was designed to be as
simple as possible, for the benefit of end users. This was perhaps the
start of the slippery slope...
Meanwhile, expansion strings have been continuously extended and
extended and extended. Macros were invented to help with repetitive
strings, and I was persuaded, somewhat against my better judgement, to
implement inclusion facilities and conditionals for the configuration
file.
Then came Exim 4 and ACLs, which were modelled on access control lists
in other applications as a series of yes/no rules rather than an
imperative language. The origin of this type of configuration elsewhere
was, I suspect, again a desire to have something that is quick to
process. (Firewall rules are a good example.) The ACL rules made use of
the existing expansion and list handling facilities in Exim, because
they were there.
Thus, we end up where we are today. Meanwhile, processors have got
faster and faster and perhaps the concerns about how much resource is
required to process a configuration file are not as relevant today as
they used to be. After all, it is well known that processing email
hammers the disks rather than the processor.
As far as multi-line macros go, I see why you want them, but I think I
agree with what I think OPs are saying, which is that perhaps the time
has come to have a more radical re-think rather than bolt on yet another
extension. (Were it a very small patch, I might think differently, but
it isn't, and the facility is fiddly to integrate into the current
code.)
Now, as for the practicalities:
(a) Such a large patch is too late for 4.53 anyway; I will be putting
out another release candidate very shortly (probably within the hour).
(b) A more radical re-think is not going to happen (at least not by me)
in the near future, because I have too many other things to do. Sorry
about that, but it's something I can't do anything about.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
