A better client and server platform for email based applications
I had an interesting conversation with Adam Doppelt about rich email based applications.
Why hasn’t anyone created a platform for rich email based applications that is as open, easy to use, and powerful as the web browser/web server combination? To do this right would involve greater simplicity on the server than any solution I am aware of, and greater richness and hookability in the client than currently exists.
By email based application, I mean an application which can be accessed by sending and replying to emails without clicking on a link to launch a separate web browser session. Email has some unique qualities that it the perfect transport for certain types of applications– for example, an email can spread virally, and the inbox metaphor allows the user to easily categorize and retrieve past interactions.
It’s harder and more constraining than it needs to be to build email based applications. I can write a script using CGI or another open standard that will do something in any web server anywhere, but there is no standard for email applications that is as simple or as ubiquitious. On the client, there is almost no control or hooks over what happens on the client, so it’s difficult to create applications that are easy to use or reliable.
There are interesting innovations that can happen on both the client and the server make this happen.
Consider evite as a very simple example. I shouldn’t have to leave my email client just to read and reply to the invitation. Building the server side of such an email application should be no more complicated than building a web page. The evite application, if trusted by the user, should be able to hook events like replying to or forwarding an evite and invoke appropriate applicaiton specific logic.
A key part of enabling email based application is a trust and security model. On the client, there should be a model for trusted applications that allows users to:
- authenticate the identity of the sending application
- allow the user to decide whether they trust a particular application to invoke scripts, load images ,etc.
A trusted application should be able to:
- run client side scripts to support rich forms with behavior.
- invoke custom client side logic when the user replies to or forwards a message. For example, it might prepopulate the reply to text or notify the server when a message is forwarded.
For example, when the user replies to a message, the application might prepopulate the reply with a form and restrict user edits to this form.
On the server side, defining a new email handler should be as easy dropping a file into a directory. The system should handle extracting the appropriate parameters from the request and dispatching it to the appropriate handler. I see this as exactly analogous to what happens with CGI scripts or Apache modules.
I realize that there a number of different Unix based email systems which support extensive customizability via scripts, but (to my knowledge) they are focused more on an administration and end user customization than rich applications, they tend to be tightly coupled a particular email server, and they are often difficult to use.
I believe there is room for an open solution that focuses on applications, simplicity, and ubiquitiousness across a range of platforms and email servers. The client side can be built as an extension to Thunderbird; the server side can be implemented independently of any particular email server using POP or IMAP and could probably be defined as a small set of additions to the CGI standard.