Autor: Christoph Kliemt Data: Para: exim-users Assunto: Re: [Exim] Adding eciscan to exim
Matthew Byng-Maddick <exim@???> writes:
> 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.
There is no need to rewrite everything. My idea is to split to code into
a "exim-kernel" and a set of interfaces where apache-like modules come
into play.
[...]
> 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.
/me too
> 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.
With the module-approach you would have the choice which one you want to
use.
> Look hard at what has made Exim successful and why you use it.
Simple. The exim-concept of acl/router/transport is the best thing since
sliced bread.
> 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).
autoconf? *shiver*
I dont see a portability problem. The "kernel" can still be written in
C; C++ is ISO, 'extern "C"' exists,gcc runs on so many platforms...
> If you want to write an MTA in C++, Christoph, feel free to go ahead.
I dont want to, sorry. ;-) The reason for C++ is that it offers a
cleaner way to describe interfaces than C does. Example: Think of an
abtract "class Transport". Inherit, implement the required methods,
done.
[...]
> Sorry for ranting, but this thread is getting rather carried away with
> itself, and crossing bridges before they're even encountered.
