I worked at Be from December 1996 to December 1999. Among other things, I answered the email sent to one of our most public email addresses ([email protected]) for two years. I remember BeMail well, and mostly fondly.
> E-mail under BeOS was implemented quite cleverly. It was actually split into > three separate parts: retrieval, composing/viewing, and browsing. The > “retrieval” part was handled by a daemon which periodically retrieved mail > and stored it in a local folder. This didn’t really have a UI, though there > was an applet to configure it. Messages were stored as a file-per-message and > indexed by BeFS, pretty similarly to how Mail.app stores .emlx files and lets > Spotlight index them. As a consequence, this daemon didn’t necessarily have > to be “the” way messages arrived on your system. You could rsync them if you > really wanted: the daemon’s sole purpose was, essentially, file transfer, > with the twist that instead of talking FTP or SCP or something, it spoke POP3. Not quite. The POP daemon did more than just download messages and create files, it was responsible for creating the BFS (Be File System) attributes (metadata) that corresponded to mail headers (To, From, Subject, etc.). This is something you couldn't do with rsync then, and probably couldn't do now, unless you were rsyncing from another HFS+ file system. Something has to create native file system attributes, and all copies need to preserve (or re-create) them. Tricky. But not impossible, Spotlight has something BFS never did, per-file-type importers. Save the files with the right file extension, create a custom importer for the files, and the appropriate attributes should be created by Spotlight. (At least, that's how I understand it.) > Composing was handled by the “BeMail” program, which could view individual > messages and provide a composition window. It knew how to talk SMTP and read > message files, and that was about it, really. It, like the daemon, was > theoretically replaceable (I can’t recall if anybody did, but it would > certainly have been a lot easier to replace BeMail than it would be to > replace Mail.app). BeatWare (horrible name) created Mail-It. Like BeMail, it could only handle POP. It was pretty buggy, and never solidified as a truly usable application. (And BeMail was always a "lite" client, with only basic functionality. I was never able to replace Eudora with BeMail, in spite of our engineers asking us to do so.) > The part which tied all of this together was actually Tracker, the BeOS > equivalent of Finder. Much like Finder, Tracker could have different view > settings per folder, but unlike Finder, this went as far as being able to > select precisely which bits of indexed metadata were shown as columns. For > mail folders, the usual Name/Kind/Modified get hidden entirely, and instead > you’d get From/Subject/Date Received. In other words, Tracker (Finder) windows were the message list views. > The three parts worked together fairly seamlessly, because each was very good > at what it did: the mail daemon just fetched mail, the BeMail just viewed and > composed individual messages, and Tracker… well, Tracker just listed files. I seem to recall that as much as we advertised that the different parts were decoupled, when BeatWare actually started implementing their alternative client, it became apparent that there were dependencies. Nothing fatal, with enough time and engineering effort, this could have been resolved, I'm sure. > I don’t know how much of this could ultimately be applicable to a Mac OS X > e-mail client, but I’ve experimented a little over the past couple of years > and turned up a few interesting results. My recollection is that BeatWare originally wanted to remain completely decoupled, like BeMail, but found that to provide a complete user interface, they needed to re-integrate pieces. Some of this was (as mentioned above) technical issues with the BeOS components, but I definitely remember in my self-imposed BeMail-only trials, it turns out the Tracker (Finder) could do 80% of what you'd want a message list to do (which is remarkable given that it was just a file manager), but was _never_ going to do the last 20%. It's been a decade, so I don't remember what the issues were, but I made real efforts to use BeMail as my main email client, and (due to the volume of messages I was handling) it was too painful to continue more than a few days at each trial. I think that it would be an interesting experiment to engage in today -- the state of the art has come a long way -- but it's one of those experiments that you hope someone _else_ will do, before you need to act on the results. :-) The other issue I see is that POP is a vastly simpler protocol than IMAP. How do you have files on the local disk also correspond to messages on the IMAP server, without the viewer client knowing about IMAP? Hard problem, I would think. MacFUSE isn't magic. At Be, one of the top user-level feature requests we got was for IMAP, and basically the engineering team told me we would never do it, too much effort. "Third-party opportunity." FWIW. Michael --- Michael A. Alderete <[email protected]> tel: +1 (415) 609-5757 <http://aldoblog.com/> _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
