What is e-mail in Chandler?

I see two possibilities, but there may be more.

Transport

In this option, e-mail represents SMTP/MIME transport. This option seems to mesh with how e-mail exists today. What is "e-mail" except a block of text formatted to be transported via SMTP/MIME?

Or do we want to support other forms of transport, like intranet systems mentioned here: http://en.wikipedia.org/wiki/E-mail?

A more concrete example of other transport systems can be found here: http://en.wikipedia.org/wiki/Blitzmail

Note that BlitzMail is being phased out at Dartmouth.

Implications

• This form of transport could in theory be applied to any Chandler Item (Annotation on a ContentItem^??)
• Introduces coupling between "transport" details and many things modern mail readers do.
  • For instance, threading support may rely on transport details like MIME headers

Structural

In this option, e-mail represents some sort of structural entity. Here's a brief list of what it might entail:

• Clear concepts of sender(s) and receiver(s)
• Inline/ external attachments
• Threadability
• Unread vs Read states
• Persistence: we should maintain a store of e-mails received in the past.

This would imply a clear separation between e-mail and transport. Transport such as SMTP/MIME would likely be a separate layer.

However, wouldn't we want to be able to send this thing some other way, eg, via instant message? Then is this thing really an e-mail, or just a complex Note? Isn't the concept of e-mail tied to transport? Doesn't "preparing something as an e-mail message" really mean that we want to send it via SMTP/MIME?

Implications

• ...

---

Thoughts

This is partially a semantic issue, and the term "mail" might actually be holding us back. At the same time, e-mail is one of the most familiar computer metaphors in the world, so we shouldn't toss it.

Is either of these is really a "design" issue in the sense of Chandler's design list? Both could probably accomodate just about any end user scenarios we could come up with. However, one may be better suited for making the implementation clean and maintainable.

-- TravisVachon - 31 Aug 2006