IMAP debate

[bscott at ntisys.com]

On Sat, 18 Oct 2003, at 10:52am, plussier at mindspring.com wrote:
> Based on the stupidity of the UW IMAP design, I'd never use it for more
> than a couple people in a non-critical environment.  It completely falls
> over with large numbers of users who have large folders with many messages
> with many large attachements.

  To be fair, this has more to do with the design of mbox/mbx then the
design of UW-IMAP.  mbox/mbx are simply not well-suited for how many people
use email today.  Namely, large numbers of messages in a single mailbox,
and/or large file attachments.  The lack of a persistent index makes mbox
pretty much the worst format imaginable.  Even with mbx, purge/expunge is
absolutely horrible.

On Sun, 19 Oct 2003, at 12:27pm, p.lussier at comcast.net wrote:
> Well, it's that, and the fact that to delete/expunge messages, it first
> copies the entire mailbox to /tmp, unlinks the file, then copies the
> mailbox back to var/spool/mail one message at a time, skipping the
> messages flagged for deletion.

  The thing is, that one minor implementation detail can be easily changed,
but mbx would still suck mud, and mbox would still suck radiologically
contaminated mud.

  Of course, there is also the question of designer intent.  The UW-IMAP
people obviously favor mbx and dislike mh/Maildir.  I regard that as a poor
decision, but hey, it's their code.  They seem to have a grudging respect
for Cyrus, but make the legitimate point that, if you want to use Cyrus, you
should just use Cyrus.

> The nice thing about Cyrus, from what I've seen is that it's similar to MH
> in the sense that each message is a separate file.  You want to delete a
> message, you delete that file. You need to rename a folder, you mv the
> directory.

  The important distinction between mh and Maildir and Cyrus, at least as I
understand it, is that Cyrus keeps a persistent index, while the other two
do not.  So, given that, and the one-file-per-message approach:

 - Mail delivery is quick (add new file, update index)
 - Listing the mailbox is quick (read index)
 - Opening a specific message is quick (read index, open file)
 - Purge/expunge is quick (unlink file, update index)
 - Lock contention is vastly reduced (index writes are about it)

  About the only downside is that it eats up inodes *much* faster then most
applications.  But that is easily compensated for.

  As I can see it, about the only thing mbx wins for are read-only and
append-only mailboxes.  For example, mail archives, and ISP mail spools.  
In those cases, you don't gain anything by sucking up inodes and directory
space for mh/Maildir/Cyrus storage.

  mbox sucks for everything.  :-)

> The other nice thing about it is the database for user authentication.

  That is, again, an implementation detail.  You could just as easily do
this with mbox, mbx, mh, Maildir, or whatever.  It's just a Simple Matter of
Programming(TM).

-- 
Ben Scott <bscott at ntisys.com>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.              |