On Tue, 28 Oct 2003, at 3:28pm, [EMAIL PROTECTED] wrote: > As for Cyrus, I don't know enough about its implementation details to > really distinguish it from maildir.
It is somewhat similar in concept to mh and maildir, in that a mailbox-is-a-directory, and a message-is-a-file. Various persistent indexes and lists are part of the format. It is also designed around certain assumptions (a single, global, unified namespace for all mailboxes; mailboxes do not need to be association with Unix users; support for multiple disk partitions within the unified namespace) which may not be immediately evident. >>> Data corruption happens. >> >> That is not an acceptable attitude for many. Nor should it be, IMO. > > In principle I would agree, but be practical: we're talking about e-mail > here. Yes, indeed. And for many companies, including many of our clients, e-mail is their single most mission critical application. > We're also talking about a disk failure. Well, I wasn't. I'm talking about any kind of system crash. I expect disks to be protected by RAID. But we've all seen even the best-designed systems crash; that why we have journaling filesystems in the first place. > So in any event, restoring from back-ups will be NECESSARY. Um, no. A properly designed system (one that employs journaling techniques) should be proof against this. Such techniques are even readily applicable to existing formats like mbox. > I still think this really isn't an issue worth worrying about. I think it is, and I don't have the option of just dismissing it, as you do. >> Microsoft Exchange, for example, deals with this particular problem very >> well, by using a journaled database for storage (Exchange has a host of >> other problems, of course, but that's not the point I'm making here). > > Perhaps so, but that feature may also be part of the cause of some of > those other problems you mentioned. As I said, that's not the point I'm making. FWIW, I don't think the database format is why Exchange is such a pig. > As a side note, I'm curious: how do those users retain only the last 6 > months of e-mail? Is that a feature their client provides? No, they just sort their inbox by date, and clean out the last X number of messages periodically. I've encountered a few different people who do this. I suspect it's not all that common. I'm pretty sure the "never delete anything; everything in my inbox" mentality is much more common. >> and you still have locking issues for mail delivery (which can be >> significant with a big inbox). > > You need to lock, but so long as you don't allow REMOTE access to the > mail spools (i.e. NFS), this just isn't a big issue. Oh, I also forgot to mention that mbox doesn't support simultaneous shared access, which is one of the more useful features of IMAP, and something that businesses will make extensive use of, given the chance. >> Maybe, with the right code, mbox can be made to suck a lot less, but it >> still seems like you're trying to improve upon a bad idea to me. Why >> bother? :-) > > Three reasons: One. > - backward compatibility This I see as the big one. And it *is* a big one. As it happens, for our customers, we use IMAP pretty much exclusively, so backward compatibility in the mailbox format (for MUAs running on the mail server) is pretty much a non-issue. But that's not the case for many. > - many people still LIKE mbox, for various reasons That's not a reason. That's an assertion that there are reasons. > - I still say that there's nothing inherently wrong with mbox... > only with how people implemented it and use it. That's not a reason. It's a reiteration of your assertion. > It has lasted 30 years and is still in widespread use, despite > availability of a number of "better" alternatives. It can't be all THAT > bad. The longevity of something has little to do with how good or bad it is. (Examples: COBOL. IBM mainframes. BASIC. MS-DOS. MS-Windows.) -- Ben Scott <[EMAIL PROTECTED]> | 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. | _______________________________________________ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
