Does MobileMe’s Push Email Really “Push?”

When Steve Jobs first announced “push email” for the upcoming iPhone 2.0 software, I was skeptical.  The two protocols I knew of, POP3 and IMAP, operate on a protocol that is always initiated by the client.  The user has to continuously check in with the server to see if new messages have arrived.  With POP3 and IMAP, you can approximate push email by polling server several times a minute.  I figured that Exchange supported some sort of persistent connection that allowed push, but from the way it was presented at Steve’s keynote, it seemed that they were touting push email for any mail account accessed by an iPhone.  I wrote off “push email” as a marketing ploy.  Im my mind, the mail server would have to know where the client was at all times to “push” updates.

Well, it turns out that MobileMe supports Push-IMAP, a relatively new protocol.  The way it works is a client logs into the MobileMe server with a long-lived HTTPS connection.  Through this connection, the client sends any updates to the server.  The server sets up a long-lived response to send back notifications of new messages.  Data is compressed to help lower bandwidth requirements.  P-IMAP is an open protocol and a P-IMAP to IMAP bridge can be set up to allow legacy mail servers to provide push services.  In addition to email updates, P-IMAP allows other data, such as contacts and calendars to be synchronized.

What seems surprising to me is that Apple is going to have to set up a system that will have to handle millions (well, at least thousands) of simultaneous connections.  Let’s hope they can do it!

So, is MobileMe’s push really “push?”  Well, technically, no.  The client still has to initiate and maintain a connection to the server.  If the server kept track of what IP address each iPhone had and initiated connections out to each iPhone, it would be a true push system.  In reality it’s a more scalable way to handle continuous polling.

 

More information:

P-IMAP

Location, Location, Location

One of the exciting technologies that’s getting a lot of attention is location-aware devices.  The ability to post location data to the Internet is creating some very interesting applications.

A few years ago, a company came out with a device that can be embedded in a child’s clothing or backpack.  While this was a prime example of how real-time location information could lead to invasion of privacy, there have been some benign uses of the technology.

One such use is GPS-enabled cameras.  Photographers can easily keep track of exactly where each picture is taken.  Flickr added location data to photos allowing you to browse for photos from a world map.  Lately, a lot of buzz has surrounded Yahoo!’s Fire Eagle.  It’s basically a location updating service and it’s opening up some great possibilities, one of which is wikinear written by Simon Willison.  You can use your location to fetch Wikipedia articles that pretain to landmarks and events that surround you.  A blessing for history geeks!

Another commonly foreseen application is being able to hook up with (or avoid) friends that are nearby.  Some have also suggested using individuals’ location data to measure traffic on highways and in shopping malls.  I can only imagine the sort of alternative reality games that will crop up now that developers can track players’ locations.

Of course, the major impetus for all of this is the iPhone.  Not that the iPhone’s locator technology is new, but it’s finally available in an easily usable (and easy to develop for), tight package.

An iPhone Letdown

One of the cool things with OS X’s address book is that with my old Sony Ericson phone, I could manage calls.  I would pair the phone with my Mac using address book (by pushing a little bluetooth icon).  Whenever someone called, their vcard and picture would pop up on my screen and I could choose to answer or ignore it.  Of course, I couldn’t talk through the Mac’s microphone/speakers, but it was nice when using headphones – I could still catch calls while the music was blasting.   It’s also interesting to note that under the bluetooth utility, it states the iPhone supports no bluetooth services whatsoever – no file syncing or address book syncing.  So, it’s really only for bluetooth headsets.  That’s pretty lame! 

Some Very Strange Markup

I was viewing the source of the Facebook iPhone webapp to see how they did their fancy transitions between pages, when I found some very strange HTML:

<body home=”home.php”>
<div class=”toolbar1 tops chrome”>
<u href=”home.php”><img src=”images/facebook.png”/></u>
<u class=”button plain leftButton” href=”#status”>Status</u>
<u class=”button plain” href=”#search” radio=”true”>Search</u>
</div>

How can a <body> tag have a “home” attribute or a <u> tag have an “href” attribute? I scoured the W3C spec and looked for a possible mobile HTML standard supporting it, but couldn’t find anything.Well, it turns out they’re doing some non-standard trickery by adding custom attributes to their elements. They’re then using JavaScript to get the values of those attributes and use them in their “onclick” handlers for each element. Sneaky!