Since 1996

June 23, 2002

So many hits coming in from 600 Seconds… it makes me feel guilty for not updating that often. #

Your thoughts here

I’ve decided to experiment with another Official ZedneWeb Message Board. It’s hosted by Quick Topic, which is “quick” in the sense that setting up a discussion takes one step and in the sense that it’s pretty responsive. Plus, it’s a technology demo, so they don’t have banner ads.

So… have something to say about a ZedneWeb post? Need something clarified? Have a burning desire to see your name in pixels? Tired of waiting for the next part of Out of Space? Then by all means, head over to the forum and let the world know what you think. (No registration required.) #

My ideal e-mail client

A while back, I described how web browsers could be split into four related components, each one handling a different aspect of web browsing. The idea was that doing so would make it easier to improve the browser and add new capabilities as well as providing ways for other software to use the functionality.

I’ve continued to think along those lines, and have turned my attention to e-mail. I’m one of those people who build up enormous e-mail archives, so my primary complaints about modern e-mail clients have to do with the hassle of filing mail and the effort required to switch clients, which usually involves translating the entire archive to a new format. Wouldn’t it be great, I thought, if there were some sort of standard way to store e-mail messages that different clients could share? (The short-lived Be Operating System had such a thing, and I’m told it was pretty sweet.)

Essentially, an e-mail management system needs the following parts:

The heart of the system is the repository; everything else involves getting information in or out of it. Most e-mail clients store mail in mailboxes, which usually correspond to files. This is problematic for two reasons. First, it drastically limits the ability to organize messages, because they can only be put into one category. Second, each time a message is added to a mailbox, the file is marked as updated, requiring backup software to store the entire file.

Ideally, messages would be stored in individual files. This solves the backup problem and reduces the number of different ways to access useful information. Unfortunately, most file systems handle small files and large directories inefficiently. The answer here, in my opinion, is to fix the file system, as is being done with the ReiserFS project. If that’s impractical, it’s also possible to store messages in files organized by time, rather than category. This greatly reduces the amount of duplicate backups.

In terms of organization, I would propose a mixture of indexing methods. First, the entire archive should be searchable. Second, one should be able to follow discussion threads (to the extent that information is available). Third, each message should be associated with zero or more keywords. Some keywords will be assigned manually, others by user-created filters, and some automatically. The automatic keywords would be the sender and recipient of the message, the mailing list, if any, and the In and Out keywords.

Thus, if I receive a message through the Superguy mailing list from Gary Olson, it should be associated with In, Unread, Superguy, and Gary Olson without me needing to configure the system. (Note that In and Unread are different keywords. This is because all incoming messages are associated with In, so a separate keyword for recently-arrived messages seems like a good idea.) This sort of keyword association is planned for future versions of ReiserFS, but it could be handled outside the file system without too much loss of utility.

Note that I haven’t said anything about the display of e-mail messages themselves. That’s important, obviously, since there’s no point in having a nicely organized archive of messages you can’t read, but it’s fairly simple. Most e-mail messages are just text, but it’s easy to imagine having multiple e-mail composers for various “enhanced” e-mail formats which could serve as viewers as well.

Parts of this idea have been implemented. BeOS had standard e-mail and address storage, and nmh is an example of an e-mail system implemented as separate programs. With luck, we may actually see most of this functionality implemented some day. #