Re: [Exim] Adding eciscan to exim

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Matthew Byng-Maddick
Date:  
À: exim-users
Sujet: Re: [Exim] Adding eciscan to exim
On Wed, Dec 03, 2003 at 09:53:42PM +0000, Philip Hazel wrote:
> On Wed, 3 Dec 2003, Christoph Kliemt wrote:
> > - use of C++ :
> It is probably no longer the case now, but back in 1995 there was much
> more chance of finding a C compiler on a random Unix system than a C++
> compiler.


Interesting reasoning. Although it possibly doesn't hold now, rewriting
the internal structure in what is effectively a different language (and
certainly a different conceptual model) would be, IMO, an incredibly bad
idea. Exim's code is really very very clean compared to many open source
projects, and the advantage of it being written by one person is that it
is consistent, which makes it, mostly easy to read. I've just caught up
on this thread, and I have to say that I view it with some trepidation.

Many projects (particularly the ones which have been successful) seem to
be almost dieing by committee. A lot of people think they can do better
than what's out there and produce such horrors as, for example, PowerDNS
or the half-built DNS system that develooper (the perl lot) were running
(not even alpha-quality based on its delegation responses). I'm not yet
necessarily convinced that multiple people involved in a design is a
good thing. More people have been involved in Apache 2 than 1.3, FreeBSD5
than FreeBSD4, Linux 2.thisrelease than Linux 2.lastrelease etc., and
while they've been getting more featureful, they've also been getting
less reliable. FreeBSD5 is still not really something I'd trust in
production yet. It's almost impossible for an outsider to tell what a
stable Linux kernel is, these days. I'm not sure that this is the way
I'd like to see what has been, for me, at least, a rock-solid product go.

I've seen some lovely modular interfaces, and I've seen some terrible
ones. Some of them work, some of them don't. I like Phil's approach of
keeping the complexity away wherever possible. I don't want to see the
code become an un-reviewable mess because I don't know what might be
dynamically loaded, or hugely complex because some developer thought
he'd emulate procmail.

Look hard at what has made Exim successful and why you use it. Then ask
yourself whether you really want to change those things, and why those
things weren't changed already. Look at the directions it's already seen,
and the way that the mailadmins use it. Look also at portability and
not reducing the current impressive number of platforms supported by
Exim (no, adding autoconf does *not* make your code magically portable).

If you want to write an MTA in C++, Christoph, feel free to go ahead.
See if people start using it, and submitting patches. If they do, cool,
if they don't, maybe this rant will have made you understand why not.

Sorry for ranting, but this thread is getting rather carried away with
itself, and crossing bridges before they're even encountered.

Cheers

MBM

--
Matthew Byng-Maddick         <mbm@???>           http://colondot.net/