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:
- An e-mail repository which stores all your mail and provides multiple indexes for searching and browsing.
- Incoming mail receivers which add mail to the repository as it arrives. There would probably be different receivers for different access protocols. Some, such as POP and IMAP, require an explicit check, while others, such as SMTP, involve waiting for someone else to send the mail.
- Outgoing mail transmitters which send queued mail when instructed to do so. Again, there would be different transmitters for different protocols, although SMTP is the only obvious choice to include.
- An e-mail composer where you actually write the mail before sending it.
- An address book which stores information such as e-mail addresses about people you frequently correspond with. BeOS and forthcoming versions of Mac OS X provide system-wide address books.
- E-mail browsers which provide interfaces to the repository. Why plural? Well, you might have a normal program for when you’re at your computer and a web application for when you’re somewhere else.
- A management center to provide some sort of coherent configuration interface for the various components described above. This could be part of one of the other components, or it could be part of a larger system manager.
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. #