Re: [exim] Continuing development of Exim

Góra strony
Delete this message
Reply to this message
Autor: Nigel Metheringham
Data:  
Dla: Chris Wilson
CC: exim-users
Temat: Re: [exim] Continuing development of Exim
[Comments inline, large chunks of original I don't particularly have any
comments on I've stripped out]

Chris Wilson wrote:
> I have a feeling or worry that since Philip Hazel has retired, Exim may
> see much less development and go into a kind of "maintenance mode". I
> think it's in danger of falling by the wayside if that happens.


I am not particularly concerned - thats how software evolution goes. If
something still has a niche then it will grow, if the world has moved on
then it may become extinct.

[Previous discussions on this have been pointed out]

> I like Exim's configuration file syntax, and I propose that we keep it,
> broadly speaking, and maintain backwards compatibility as much as possible.


Ah - there we differ. Config syntax is OK, but the string expansion
stuff within it is a complete mess. I would break backwards
compatibility in a huge way - not just a bonfire, but a blast furnace!

If we are talking lua, then I would throw the config handling away and
replace the whole thing with a lua parser, making the whole config be a
set of lua tables and functions. ACLs & routers would be lua functions.
The whole setup would be a combination of sections in C and lua extensions.

But this is talk for a son of Exim or similar - very dissimilar.

I suspect Exim 5 will be a relatively minor update as we run out of
numbers. And thats a reasonable way to go.


> I'd like to discuss something that could turn Exim into a laboratory and
> toolkit for email programming: a complete rewrite in a modern
> interpreted language such as Python or Lua, with an object-oriented
> style, maintaining feature and configuration file compatibility, and
> with a test suite.


As said, I'd throw config compatibility because the string expansion is
such a horrid mess. Python I'd pass on - not really a good extension
language.

Really you need a (set of maybe) queue handler(s), a set of receipt and
delivery functions, and everything else is sugar and plumbing - ie
extensions.

    Nigel


-- 
[ Nigel Metheringham ------------------------------ nigel@??? ]
[                 Ellipsis Intangible Technologies                  ]