Areas to consider:

• Interoperability
  • Sending via SMTP
  • Exporting to third parties who understand MIME
  • If we break compatibility, we'll still need to have a path back to MIME for SMTP
• Representations
  • Chandler's ideas of "e-mail" compatible with MIME?
    • If not, why not?
    • If so, we could just build upon a solid MIME base. This would mean it is a good idea to have a base representation solidly based on MIME right now.
    • I get the sense that this is possible. A good discussion of Chandler's plans for e-mail would be useful. It seems like this is what is happening right now on the design list, so this may be a problem in the middle of being solved.
  • One thing I do know about e-mail in Chandler is that it is seen as a verb, not a noun. This is very compatible with MIME. A MIME representation is a standard representation of a communication, that is, the action behind the verb.

MIME is to the verb "e-mailing" as a photon is to the electromagnetic force. That is, it is a good (and, frankly, mandatory because it is so closely tied to SMTP) transmission format. For this reason, a path to MIME from any Item we'd like to e-mail is fairly mandatory.

However, MIME also suggests a natural way of storing itself (that is, a tree structure which can be recursively processed).

The question is whether this mode of storage will ultimately interfere with Chandler's goals for e-mail. If there is a good chance it will, we should do what is best for Chandler. Otherwise, it makes sense to build on the base of the MIME structure.

Building on this base has other advantages:

• MIME is similar to the format used by HTTP (headers, content types, etc). According to the HTTP RFC, "In general, an HTTP user agent SHOULD follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type." If we have ambitions of Chandler doing HTTP, it might be nice to have this framework already in place.

There are still downsides:

• Probably the largest is having to tackle the task of reconciling the two systems. A couple examples:
  • In Chandler, we would like to be able to "promote attachments to first class Items". This seems like a very good idea.
    For instance, if an image or calendar is attached to an e-mail message, that image or calendar should be turned into the appropriate Chandler Item and made available to the Chandler ecosystem. However, if these attachments (let's say a calendar) are treated as MIME Items to maintain compatibility with the MIME message system, the current system results in a choice between two sub-optimal scenarios:
    • The existence of two different sets of calendar-like kinds: one Chandler specific and one that reflects the MIME message properties. OR
    • The conversion of MIME-calendar attachment objects to Chandler specific calendar objects, and the appropriate mechanisms to translate back for use by the SMTP (and anyone else requiring a path back to MIME). This is the approach currently used by the osaf.mail.message module. This could get quite complicated, as each kind which would like to support MIME will need conversion functions.
• The inverse of this is the fact that while we would like to be able to "e-mail" any subclass of ContentItem, we currently have separate Kinds for e-mailable "stuff". Thus, when we want to e-mail a calendar object, we create a new MailMessage object with a calendar as an attachment. When we want to convert back, we use a custom method in MailMessage. This strategy seems less than ideal, as we will need to add a new such method in MailMessage for each Item we'd like to be able to e-mail.

Annotation as an alternative

One alternative which I believe would offer a number of advantages would be to encapsulate the properties of a MIME message in an Annotation class "MIMEObject" which would annotate ContentItems. The annotation class would keep track of a set of headers, a payload, and a content-type. It would provide functions for getting the headers of a MIME message and perhaps include a default conversion function for creating an email.Message.Message object^†. This Annotation class could then be subclassed if and when it was needed.

This change actually might not be too complicated to implement. Right now, all MIME* and MailMessage* classes are derived from ContentItem by way of MIMEBase. If we made MIMEBase subclass schema.Annotation and annotate ContentItem, the refactoring in osaf.pim.mail would be done!. The remaining work (which might be substantial) would be in existing code that uses MailMessages as first class items. Instead of storing MailMessages, we would store the underlying Note object, and use MailMessage(note).attribute whenever we needed to access a MailMessage specific attribute.

I believe this system has a few advantages:

• The system becomes more flexible. Any ContentItem can easily be turned into a MIME message by simply annotating it, specifying a payload, setting some headers, and providing a content type.
• This actually helps pull e-mail back from a noun to a verb. That is, e-mail is no longer a first class item, but something that can be done to any kind of content item. This actually seems like a BIG win!
• The concept of headers could be pretty flexible. It would be easy specify headers explicitly (via a dictionary like {'Subject':'Re: sweet as, baz'}) or with a mapping to attributes (like {'Content-type':self.contentType}.

I'm not sure what the time frame on this kind of change would be, it probably depends on the amount of code we'd need to change to accomodate the new Annotation system.

---

^†This function would utilize the payload variable and headers variable, which would be dynamically specifiable. For example:

>>> class NewChandlerItem(schema.Item):
...     body = schema.One(schema.Text)
...     
>>> item = NewChanderItem(view=someView)big change
>>> item.body = u"I've got body!"
>>> mimeMsg = MIMEObject(item)
>>> mimeMsg.payload = mimeMsg.itsItem.body
>>> mimeMsg.headers = {u"Spam":u"eggs"}
>>> mimeMsg.contentType = u"text/plain"
>>> print mimeMsg.getText()
Spam: eggs

I've got body!
>>>

Subclassing MIMEObject could create even more complex items by using property() to create access methods for payload. Instead of mapping payload to a specific attribute, a function could be created that would process the ContentItem and return an appropriate representation.

-- TravisVachon - 18 Jul 2006