IMAP debate

[bscott at ntisys.com]

On Tue, 21 Oct 2003, at 4:43pm, invalid at pizzashack.org wrote:
>> The lack of a persistent index makes mbox pretty much the worst format
>> imaginable.
> 
> There's no reason why your client can't provide such a thing, even if your
> mail system as a whole does not...

  My understanding is that mbx is more-or-less mbox with a persistent index
added on.

  I might point out that, for an IMAP server at least, client-side
persistent indexes are just about useless.

>> Even with mbx, purge/expunge is absolutely horrible.
> 
> If you re-write the folder in place, expunging a few messages from the end
> of the file will not take long. This should be the common case, logically.

  The problem with re-writing the folder in place is that an interruption at
the wrong time corrupts the mailbox, leading to lost data.  That isn't
something I would want to use.

> Especially arge folders tend to be archive folders.

  Heh.  For a great many people, it appears an "inbox" is considered an
"archive folder".  :-)

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 ...
>>
>> The thing is, that one minor implementation detail can be easily changed
> 
> a) This is NOT a minor implementation detail

  Um, how hard would it be to change the location of the temporary file from
/tmp to the direction the mailbox is in?  Granted, I haven't looked at the
code, but I have a hard time envisioning an implementation where this would
not be a quick fix.

  A heck of a lot quicker then all the code (re)writing you so off-handedly
suggest for mbox.  :-)

> Mbox clearly has some disadvantages, but its creators were not idiots.

  I'm not calling the creators of mbox idiots.  Nor do I intend to imply the
problems with mbox are due to designer brain damage.  I probably should 
have stated that explicitly, though.

  mbox satisfied the requirements at the time.  We're talking about reading
a few messages at a time using a mail reader not more more sophisticated
then "more /usr/mail/jsmith".  I doubt they envisioned file attachments,
thousands of messages, IMAP, shared mailbox access, or any of the other
abuses to which mbox has been put.

  However, the facts that mbox design is something like twenty years old,
and was never designed for what it is often asked to, does not alleviate the
problems it has when put to those (ab)uses.  :-)

> Maildir also has disadvantages.

  [bunch of disadvantages deleted]

  Yes, all those are well-known, and frequently brought up by the UW folks.  
You'll note that I was not talking about Maildir or mh, but Cyrus.  The
persistent index which Cyrus maintains eliminates most of them.  The rest
are, as you note, easily eliminated by spec'ing the filesystem to handle
Cyrus in the first place.  Which seems like a no-brainer to me.

> My contention is that for operations which matter most, mbox is actually
> faster or sufficiently fast enough, in the common cases, that there is no
> clear performance winner between the two formats, given efficient
> implementations of both.

  All I really know is this: In a production environment, with an IMAP
server, given the way most companies use email these days, UW-IMAP+mbox is
orders of magnitude worse then Cyrus.  The difference is enough that an
mbox-based system basically thrashes to death due to load, while Cyrus chugs
along nicely.

  Contend all you want.  That's what we see in real life.  :-)

-- 
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.              |