On Mon, May 7, 2012 at 3:25 PM, Chris Wilson <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
