Timo Sirainen wrote:
While the maildir format itself is simple, it's actually really difficult to handle correctly when the maildir is changing under us. Files can be renamed at any time so you'll have to be prepared to look for the file's new name at any time. Filesystems also don't work the way maildir assumes they do, so you have to work around their limitations too.
I thought that was the point of dovecot-lda, so that you know that dovecot is the only process touching the message files and can update the indexes as things change, rather than after the fact. Too bad you cannot write a portable FS hook that would fire when the directory changed.
This could possibly be also automatically set per mailbox. If user always expunges all mails at a time (POP3) or never expunges (mailing list archives), there would be only a single file.
If you are thinking that way, it might be useful to mark mailboxes as either:
a) sequential access (most POP3 and archives);
b) random access (IMAP).and provide different tuning based on usage expectations, rather than trying to actively tune. Then the system admin could choose which fits their needs best; we only have a few people using POP3 and everyone else is IMAP, and I frankly don't care what kind of performance the POP3 people have.
I think SQL database as a mail store would have much worse performance than with any filesystem based mail store.
Except that with clustering, you could have multiple DB servers getting hit by multiple dovecot servers. SQL could potentially scale to much larger environments than filesystem support. Plus, think of all the neat fulltext indexing possibilities.
I suspect GMail is based on SQL... ;-)
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748