In message <20070215171716.GA22243@???>, Mike Cardwell
<exim-users@???> writes
>Someone recently mentioned the possibility of abstracting the storage
>out so multiple types of backend could be implemented. That's one
>of the best ideas I've heard in a while.
seconded ... why have a war about what sort of storage is best, let
people build what they think will help them ! they have different things
to optimise.
I'd suggest that the aim for Exim #5 ought to be to modularise
significantly, so that several different designs are possible within the
same overall architecture. That's already the way things have gone with
spam filtering schemes.
... but I'm surprised that no-one has mentioned queues yet (for me to
notice anyway). Quite clearly a key design aim for #5 should be to
revisit the assumption that the majority of email can be quickly
shuffled off to somewhere else.
Exim doesn't work terribly well for the bulk of email going through ISPs
that cannot be delivered anywhere at all :( It's fine if you can
promptly decide that -- otherwise it sucks :(
Other major subsystems should become modules so that multiple parallel
implementations can replace the existing design. Maildrop style is one
(where the code for several schemes is already present), what else?
The big plus is that Exim is mature enough to see what the grand overall
architecture should be : building from scratch something with a
selectable modules style of design can lead to significant inefficiency
as one goes through "we'll give them a choice here" interfaces to no
practical purpose.
- --
richard Richard Clayton
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. Benjamin Franklin
