Re: mailbox format(s)
Bruce Lilly <[email protected]> Fri, 27 Feb 2004 15:34:59 -0500
| Newsgroups | gmane.mail.ng |
|---|---|
| Organization | Bruce Lilly |
| Message-ID | <[email protected]> |
Iljitsch van Beijnum wrote: > > On 27 feb 2004, at 0:26, Bruce Lilly wrote: >> If the mailbox is accessed via a standard network protocol such as >> POP or IMAP, it is trivially easy to switch MUAs. > > > Not quite. Then the new MUA must download all the messages again from > the server. Not with IMAP, where the message store typically lives on the server (which could very well be the same machine -- the point being to delegate management of the storage to a specific piece of software other than the UA per se). >> A flat file just doesn't >> work well with even a modest number of messages. > > > It can work if you build an index and don't go around removing message > from the middle of the file too often. > >> Cyrus IMAP stores one >> message per file, with a database for metadata (access lists, >> etc.), and it's quite fast. > > > Maybe for random access, but if you need to access all messages you're > bound to be slower. Also, the file system overhead makes this a pretty > bad idea. Not necessarily. Consider a POP UIDL command, which lists the messages by UID with each message size. With a flat file, every byte of every message is read as the sizes are determined and the IDs generated. I used such a system -- it became unusable with a few hundred messages; it took several minutes to generate a UIDL response. Cyrus IMAP (using POP protocol) on the same hardware with approximately 40000 messages completes the UIDL response in a fraction of a second (generating it is simple -- each message file is named according to the UID, and a simple stat() system call gives the message size; there's no need to read each file). > What I imagine is a system where messages are stored in a binary > container format [...] I don't want to get too far into the details at this time, but a binary format is only acceptable if a text message is still recognizable as such. The ability to use tools such as find and grep is very important, not only to users, but administrators as well -- when the pointy-haired boss says "I know I have a message from John Smith somewhere, but I can't find it", would you rather rummage around in a single 300 MB file (possibly in a binary format), or just run something like grep -i "john smith" /var/spool/imap/users/phb/inbox/* ? For that matter, IMAP provides search capability with server-side support, so it's possible to search messages regardless of the client MUA, without having to keep copies of the messages for each MUA. > Standards improve quality, because they usually eliminate inferior ways > of achieving a result. And often vendors that implement their own > solution also support the standard to some extent in order to be > compatible. Among standards-conforming implementations, there can be a substantial difference in the quality of implementation. And some vendors that pay lip service to standards are often the cause of interoperability problems through non-standard "extensions" and/or broken implementations (e.g. HTML/CSS).