Hi Jan,
On Mon, 7 May 2012, Jan Ingvoldstad wrote:
> 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
Thanks, I don't know how I missed those, I've been lurking on this list
for years.
>> 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? ;)
I'm not sure I consider sendmail.cf programming as much as dark arts :)
>> 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 think Exim is considered a very high performance mail server. I
suspect that postfix beats us there.
We know there are scaling problems with dispatching from the mail queue. I
don't dare try to fix those with the current code anyway.
I suspect that the programming language overhead pales into insignificance
compared to network latency and algorithm choice (including use of
databases and indexes). Major applications are written in interpreted
languages these days (Facebook, Hotmail, Basecamp, The Onion, Reddit), and
as you pointed out, Sendmail is at least partly interpreted too.
The heavy data processing bits, like virus scanning, are often written in
C and would probably remain so; Spam Assassin is written in Perl and many
sites pipe their mail through it.
I don't think a rewrite in e.g. Python would make thinks much worse, and
it would make them easy to improve.
> In general, I think your idea looks cute, but do you _really_ think we
> could call it Exim after a rewrite like that?
I'm not sure, but I think sharing a configuration file syntax and a
commitment from the developers that this was the way to go forward, would
be enough to make it Exim in my view. That's another reason for wanting to
start discussion rather than trying to write "my own successor to exim"
which likely wouldn't go anywhere and would irritate a lot of people.
> 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.
Perhaps you're right, but I'm inclined to disagree. I think anyone using
Exim because it's flexible would appreciate the extra flexibility and not
notice the performance cost. Anyone using it as a basic mail server might
be better off using postfix these days.
> I think the suggestion on the Exim wiki about a Python API is more
> realistic for that use.
Perhaps you're right. It would certainly be easier, but I don't think it
makes Exim any easier to maintain and improve.
Cheers, Chris.
--
_____ __ _
\ __/ / ,__(_)_ | Chris Wilson <chris+sig@???> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |
