Sorry, I forgot about that one. But AFAIK it's very uncommon compared to mbox and mh. In fact, I don't know any programs using it, do you?
Well, gee, you're talking about a hack to extend mh format for c-client that mh itself won't know about. That's a different format.
For a typical usage scenario it definitely is. I didn't do any hard testing but mh was certainly much faster for me than mbox for mailboxes containing from 1000 to 20000 messages.
With what client? With a POP client hacked to babble IMAP such as Outlook, perhaps. If you actually use IMAP as IMAP, with such things as fetching envelopes and searches, you'll find something different.
I'm not interested in optimizing IMAP for POP.
MC> On UNIX (as opposed to Linux), mh is extremely slow. Traditional Unix with ufs -- maybe. But modern Unix systems (even other than Unix) have much faster filesystems.
I must disagree. I am spending a lot of cycles right now dealing with a modern UNIX system which has a horrendously slow filesystem.
If there were any chance of you accepting patches to the mh driver, I would do some tests comparing mbox and mh on a few different systems to prove it.
Since those patches won't be compatible with the original mh program, I'm not interested.
mh is a dead format. The only purpose to support it is for compatibility with the past; and without that compatibility it isn't worth supporting. The successors in the one-message/one-file style of doing things are such formats as Cyrus, mx, and yes maildir.
Getting that style to work well with IMAP is not easy. Nobody has a satisfactory maildir implementation for IMAP; it's either slow, or broken, or incompatible with DJB's maildir definition, or a combination of these.
Cyrus has special hacks in the format to support IMAP, and is focused on IMAP-only access (not local file).
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
