Re: [exim] Exim 5 Wishlist

Richard Pitt wrote:
> I can think of a couple of reasons to do this - and lots not to:
>
> for: scalable central store that multiple machines can address with
> better?(different) locking than NFS provides

More reliably - yes. But slower.

> for: different security model from disk store
>

The single most practical reason, actually, but not 'good enough', as a
combination of unix perms and Mandatory ACL's on recent FreeBSd / most Linux /
other commercial Unices, can do 'well enough'.

> against: performance - today's disk systems are essentially hierarchical
> file systems anyway - especially like Reiser.

Not really. They are track & sector hardware mapped in silicon as block-mode
devices, then *presented* as if they were hierarchical, 'coz that is what
'wetware' prefers to see.

> SQL generally requires far
> more resources for similar performance - especially with "blobs" of any
> size.

Not 'generally'. 'Always'. And by a large margin.

At the end of the day any DB must *also* map to the underlying fs - and not just
the raw data - but all of its own overhead, logs, checks and balances, bells and
whistles. Look at the potential for conflict, for example, between PostgreSQl
WAL, softupdates, hardware caching, et al. We mount the SQL partition
differently than other parts of the fs, and on differently configured RAID.

This can get complicated 'Real Soon Now'.

> RAM for SQL server takes away from RAM for disk caching.

Can be engineered around, but not for free.

> against: most messages don't hit the data store anyway if the system is
> working the way it is supposed to
> against: central database can't be replicated (potential for multiple
> deliveries of single message) so scalability is limited and means a
> single point of failure

Disagree.

DB-centric storage *may* actually makes ease of replication / fewer
single-point-of-failure management *easier*.

Not true of *all* animals with the word 'SQL' attached, but certainly so for the
better ones.

>
> There are likely others

'Wrong tool for the job at hand' comes first to mind.

Not theory. We spent several years trying it - DBMail & PowerMail, each
standalone and also partially integrated with courier-MTA, Exim, and Dovecot.

>
> Maybe you should share your reasons.
>
> richard
>
> On Thu, 2007-02-15 at 08:38 -0800, Marc Perkel wrote:
>> One thing I'd like to see in Exim 5 is an all SQL version where mail is
>> stored as SQL and there's really tight SQL support.
>>

Marc - current SQL tools in Exim are as good as they get anywhere.

- Near total support and/or agnosticism as to which/whose SQL is used and whter
connected to by IP, pipe, or Socket.

- Ability to do arbitrary SQL-ish things from any point in the flow.

Nothing more than that is needed, even if you DO want to re-invent that wheel.

Bill Hacker