Sunday, November 09, 2008

The idea of using native HTTP resources to RESTfully access an email store is not only an old idea, it's been implemented many times. Some Web mail architectures are even somewhat RESTful although the purest implementations are not themselves Web UIs -- these RESTful email interfaces have typically been built to support Web UI frontends in a classic tiered architecture.

I have been talking about this for so long that it seems self-explanatory. Emails can be HTTP resources with persistent URLs and machine-readable representations. Mailboxes can also be HTTP resources with persistent URLs and machine-readable listings of contents, we just have to agree how to represent those listings. Here's my proposal.

Atom feeds is my choice for organizing those listings. I think it's worth explaining the two overriding reasons why.
  1. Atom allows clients to just GET a representation of a feed, and the feed can contain an arbitrarily long list of items, but paged according to the server's needs. This is a great allocation of responsibility, making client logic simple and putting server performance in the server's hands.
  2. The default model for feeds is that the same object can be in more than one feed. This is very important for the usability of email going forward. I know a few people who organize their mail into strict hierarchical collections, typically using IMAP, and find old email by jumping to the right place in the hierarchy -- but I know far more who rely on giant inboxes, saved searches, flagged email or tagging. The default model for feeds directly accomodates all those usage models.
I was very happy to find once I used these principles and applied the feed model, that it fits very well so far. It's possible to implement the spec as a proxy between an IMAP server and a client. It's possible to access a mail feed with an unmodified Atom-capable newsbrowser. This bodes well for implementing and deploying.

1 comment:

helje5 said...

It would be great to rename that effort to 'atommail' instead of 'httpmail', which is already (IMHO properly) branded as being WebDAV (PROPFIND) based email. (I see Atom more on top of HTTP while WebDAV is a same-level extension of HTTP).

I would love to see httpmail (WebDAV) being put into some kind of standards draft, though WebDAV + proper content-type is already quite obvious.

Apparently the biggest issue with http/atommail is listing folder contents, since that can become really big. The ctag helps a bit, but only so much.
Plus flags of course, which are hard in HTTP (personalized WebDAV properties maybe?).

Apart from that this approach seems to be missing BODYSTRUCTURE functionality, which we found VERY useful in ScalableOGo.
Basically putting up a standard for adressing MIME parts of a message, eg:
/server/INBOX/1/2/logo.gif
Why is that awesome? Because a web UI client can directly address such a part when showing the content to the browser. And its standard functionality in existing IMAP4 servers (which might get gatewayed).

Anyways, good to see work goes forward on HTTP based email, its a good starting point.

Greets,
Helge

Blog Archive

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.