Nathan Whitehorn has written up a small article about the Mail Daemon Replacement, and how it relates to the BeoS Philosophy.

Originally intended for one of the openBeOS Newsletters, Nathan has kindly allowed it to be published on TBJ.


MDR and the BeOS Philosophy
by Nathan Whitehorn,
11 August 2003

Instead of an effort to preserve and extend a piece of software, like openBeOS, BGA and I started the Mail Daemon Replacement because the existing software, the BeOS Mail Daemon, sucked. From this realization of its suckiness over the years, we've gotten Mail-It, Postmaster, Scooby, and Beam, to name a few. And yet, the Mail Daemon Replacement (to save my hands and your screen space, to be hereafter called MDR) is qualitatively different from all of these. This is not simply because it is a background process, and not a mail client per se, although that is part of it, but because it obeys the BeOS Philosophy.

The BeOS Philosophy can't be summed up in a sentence, nor in this essay, but it is nonetheless a powerful tool of design, and, in its own way, as revolutionary as the Macintosh philosophy of human useable software was some years ago.

I have started by asserting that MDR is consistent with the BeOS philosophy and that the traditional three-pane mail reader is not. Perhaps we can arrive at a sense of what this is, then, by examining the differences between them.

BeOS Software is Transparent
The Mail Daemon Replacement is a background process, as I've said, but this is secondary to the reason it is a background process: it uses, and is integrated with, the system as a whole. The uniqueness of the BeOS way was driven home to me the other day when using iTunes on Mac OS X: iTunes has its own trash. When I delete a song there, it moves it a separate iTunes trash separate from the file system trash, which must then be emptied separately. Mac OS X Mail has its own trash too. In the BeOS, both the mail software and the music library are integrated into the file system. You can view, modify, and organize email or MP3s in the same way and with the same software you might use to organize word processing documents. The interface is an interface to the system – far more consistent than anything mandated by Human Interface Guidelines, because all the software is the same.

BeOS Software is Modular
This interchangeability and transparency of software is deeply rooted in the BeOS, and extends far beyond being able to simply organize email in Tracker. System services like the translation kit allow applications to share user-supplied system resources, and allow users to add new items to menus and use add-ons for a myriad of applications.

With this in mind we designed the Mail Daemon Replacement to be modular, perhaps to a fault. The Mail Daemon binary contains only 700 lines of code, mostly dealing with the new mail counter and initialization of attributes displayed in Tracker. All of the protocols and message parsers, new email notification and spam filter, and the code that saves messages to disk, are located in only a small set of add-ons. What is more, all MDR add-ons are interchangeable. As far as the mail daemon is concerned, the IMAP filter is indistinguishable from New Mail Notification.

BeOS Software is Oblivious
This brings up another interesting point. Most good BeOS software neither knows nor cares what it is dealing with or how it happens. Everything is abstracted to make the system extraordinarily flexible. Applications like BeShare transmit any kind of file; obliviously. It preserves the file's attributes, and even allows you to search by them, without itself knowing anything at all about them. MDR neither knows nor cares of the difference between IMAP and New Mail Notification. They are both filters. A better designed net server wouldn't know the difference between your ethernet card and the TCP/IP stack. They both process data; it's the server's job to provide it.

BeOS Software is Tiny
Good BeOS software doesn't attempt to do everything all by itself. The software itself is light on features, because the developer relies on cooperation between software. ShowImage doesn't need to be a GraphicConverter. It need only understand bitmaps, because the add-ons in the Translation Kit understand everything else for it. MDR doesn't need to worry about email display. Or about fetching email, for that matter; its add-ons do that work for it.

Three-pane mail clients violate most, if not all of these rules, by isolating the world of email within the confines of a single application. They know email. They know POP3. It's all hard-coded in. Everything is right there — and there it is all trapped.

An operating system is a symbiosis when designed well, and the BeOS is designed to be as mutually beneficial as possible. Its software doesn't need to erect walls that separate it from other applications, because everything is designed to inter-operate and provide features to others.

As we move forward in the recreation of the OS, let us not lose sight of what the BeOS is supposed to be, and what it can be. We have an opportunity to eliminate the world of applications with separate trashes forever. Let us be sure to take it.


-Nathan Whitehorn
nathanw@uchicago.edu
Dr. Zoidberg Enterprises