Merry Sneeze

Besides the usual amount of socks, brought along a touch of flu and a certain predisposition for reading - among the many books I've read these past few days, I can heartily recommend Elizabeth Moon's Speed Of Dark, and the timeless The Stars My Destination. I haven't started on my Tom Sharpe pile yet, but considering the way my sinuses get in the way of actually doing stuff, I guess it won't be long.

The Push E-Mail Story

RIM is back in the news, with its ongoing plight to license its messaging solution to just about anything under the sun. Which makes a lot of sense, since after the injunction that bars it from actually selling hardware in the US, it needs other sources of income to stay afloat.

However, I'm amazed at the cluelessness of most of the press coverage, since it invariably assumes the availability of RIM's solution on every platform is A Good Thing and touts "push" e-mail as the best thing since sliced bread (which it may be, but I'm naturally suspicious of anything that is promoted as enthusiastically). Most, however, don't even realize what "push" is.

Let's step back a bit, shall we? RIM originally developed their messaging platform (which is not literally a "push" platform, because it - like MMS - signals the device that new content is available and it then "pulls" it as part of its over-the-air sync procedure) in such a way that it provided centralized (initially -based) storage of rich content (such as attachments) and dynamic format conversion in order to make those readable on a PDA.

Allow me to explain again: there is no such thing as push e-mail. What happens is that your device gets a notification of new e-mail and then downloads a translated (i.e., barebones) version of your e-mail that your can render, plus a few tags that allow the and RIM's content translator to keep in sync (so that you can manipulate attachments and so on remotely).

RIM has effectively implemented a split-layer e-mail reader, with the central servers pre-rendering the content into a simplified (actually mostly text) markup that the device renders on-screen. Interaction is smooth and efficient because the client is very closely coupled to the central format translator, and because the data that actually needs to be transferred is very small.

Now this is not that much different from, say, webmail over WAP with a decent (i.e., large) mobile phone screen and a set of attachment filters on the server side to perform the format translation. In fact, WAP might actually be a bit more efficient than the RIM protocol, since it was painstakingly designed to work with just about any mobile phone - and if you use it on a link with a large-size display like a Palm, it's actually fast and usable.

Of course, you don't have the same user interface (WAP has a fairly restricted - and stupid - set of WML widgets), but the only thing we need from it is the text packing and rendering - the user interface can be wrapped around a WAP browser (in mostly the same way as some applications wrap or Internet Explorer) and provide menus, buttons, dialogs, etc.

RIM didn't go with WAP because they didn't have a bunch of vendors alongside them doing design by committee (which explains WAP's schizoid approach at reinventing ) and needed to target just the one platform. But it seems to me that adding a number of new clients to the mix will either result on a uniformly "bare" experience (not taking advantage of each device's strong points) or in subtle, annoying differences in functionality.

As always, we'll see. The was a modest success in the US. And I say "modest" deliberately - it catered to the needs of a fairly confined market segment, and people should develop a sense of proportion when dealing with mobile data. Besides, there were no real alternatives for mobile messaging when it came out.

In Europe, with its prevalent SMS culture, MMS and on the rise and ready availability of PDAs supporting IMAP (which lets you read all your messages quickly without downloading attachments), the only edge RIM has is its content adaptation server.

I wonder if it will be enough.

This page is referenced in: