On Mon, May 7, 2012 at 3:25 PM, Chris Wilson <chris+exim@???> wrote:
> Hi all,
>
>
Hi there!
> 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 would be interested to know anyone has plans for future development, in
> particular what we might call "exim 5"? I have some wild ideas that I'd
> like to throw out there to see what people think. I expect to get flamed
> for some of them :) I don't expect them all to succeed, but hope that they
> may start interesting discussions.
>
There have been some earlier discussions touching on the future of Exim
before, e.g. the 5.x thread here:
https://lists.exim.org/lurker/message/20110517.154641.82c355f9.en.html
And the Exim 5 wiki:
http://wiki.exim.org/Exim5
I agree with your general points that there may be room for simplification,
but it's hard to both simplify how things are handled _and_ keep the
backward compatibility you desire.
I think it's better to start off at least somewhat cleanly, and instead
maintain the 4.x branch for backward compatibility.
> Finally, I think exim's venerable and complex code makes it difficult to
> contribute. I also see exim as a kind of experimental/expert/**programmable
> mail server, allowing us to do things that no other mail server would, but
> also full of ancient, inherited quirks.
>
Are you sure you're not talking about Sendmail? ;)
But yes, contributing to old projects may be challenging, even for
experienced programmers.
I haven't tried digging into the source cod myself, so I can't speak for
the veracity of your comment here.
>
> 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.
>
Certain parts of a mail server need to be optimized for speed in terms of
response times. While Python certainly is a very practical language to
program in for those who are comfortable with it, I don't think there's
much of an argument that using an interpreted language probably would not
improve things.
I don't know about Lua in that regard.
In general, I think your idea looks cute, but do you _really_ think we
could call it Exim after a rewrite like that?
It seems to me that what you really want is something that is a simplified
version of Exim, which shares the configuration language (at least in a
simplified form), written in an interpreted programming language, for
educational purposes. I think that can be done, but I don't think it can be
done _and_ replace Exim in email servers around the world.
I think the suggestion on the Exim wiki about a Python API is more
realistic for that use.
--
Jan
Just another Exim user
