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, [EMAIL PROTECTED] Cambridge, England. Phone: +44 1223 334714. -- ## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
