Thank you for a very well thought out *open* message. I would guess that most of
these reasons are why DBMail was started 5 years ago ;)
I'm gonna response with some pro-DBMail stuff... just because it's in my head
and pretty much addresses all of Marc's comments below.
Marc Perkel wrote:
This is still visionary so take it for what it's worth. People are more
familiar with MAILDIR and MBOX because they are files. You can read them
with VI and PICO and FGREP and all the stuff that we are familiar with.
MySQL is also easy but might require new tools and some learning. Once
you become familiar with it them everything is just as easy.
One could expoir and import to and from maildir and mbox, so that
doesn't go away.
DBMail has both a maildir import and export.
With MySQL there are a lot of problems that go away. MySQL is a magic
port that does everything for you. It doesn't care about what filesystem
you're using, what OS you are running, what kinds of file locks or NFS
mounts, or if you're using Reiser for maildir speed or if you have
enough inodes. All that stuff goes away.
One of the great aspects of DBMail... SQL Clustering and replication independent
of the OS. Cyrus and other great IMAP server have only recently gotten this
working in Alpha versions. Otherwise it would require very expensive storage
solutions to get any kind of failover or "realtime" replication. With
DBMail/MySQL just setup another cheap server and configure replication done.
MBOX and MAILDIR have no indexing. You can add indexes externally but
there are no standards for that. With MySQL you can index anything and
everything. You can add fields to the message, any fiels, as many as you
want, and they too can be keys and indexes. With maildir and mbox you
can't really do that.
Many of the filesystem storage solutions do have indexing, but in file hashes.
Zimbra has gone so far as to have a filesystem store with MySQL indexes for
speed. As you point out these are not "standard" and don't scale unless they are
on an expensive storage solution.
With MySQL you can access the data with any MySQL application. And the
access is consistent no matter what programming language you use, what
OS you use, anything. It's all SQL. So if you want a web interface you
just write a PHP app.
There are a number of PHP and other scripts that access SQL directly for
everything from webmail to administration... works great and very easy to work with.
Spamassassin for example has migrated from GB files to MySQL for the AWL
and bayes and we all can see how this has improved performance and ease
of implementation. Before SQL having 5 servers sharing the same bayes is
difficult. With SQL it's trivial. The SQL does it all for you. They do
the magic so you don't have to.
The indexing is a real key feature. If I have a key based on the sending
host or index all the received lines, I could delete all messages that
had an IP in any received line almost instantly. I can do it thousands
of times faster than mbox or maildir because it's indexed. Indexing
gives you incredible power and the SQL engine does all that for you.
That SA and the IMAP and the MTA and the Web GUI - everything - all
taking to a standard database - all integrated - all comnpatible.
So - like I said - this is visionary stuff. Think SQL - think outside
the box.
It is visionary in that it is not the "norm", but again DBMail does all of
this very well and has been production quality for quite some time.
This is a great thread, but as far as starting a new project I'd just go with
what is already working. DBMail is built in C, so very speedy.
Someone mentioned rewriting an IMAP server in perl... not sure if I'd go that
way from a speed standpoint, but would certainly be interesting.
If you are looking for another approach Zimbra is written entirely in Java and
Open. It uses only MySQL indexes, but would be very straight forward to replace
its existing MailStore Class with one that writes to MySQL rather than the
filesystem.
--
Kevin Baker
begin:vcard
fn:Kevin Baker
n:Baker;Kevin
email;internet:[EMAIL PROTECTED]
tel;work:858-454-5532
version:2.1
end:vcard
