IMAP4 (Internet Mail Access Protocol) is a little discussed but widely used protocol for accessing and managing email. As it turns out, IMAP is also a great way to deliver information to mobile applications, by repurposing mobile IMAP clients for use in a wide range of mobile applications. While this is a bit of a hack, since we’re using a protocol designed for one purpose for an unintended use, it solves several problems that plague mobile applications.
IMAP is designed to do one thing and do it well — deliver email despite the intermittent connections that were prevalent when it was developed. For that reason is baked into nearly every email client and mobile device. Email delivery is also one of the most thoroughly tested services on mobile devices, and is designed to operate as an always on, background service.
IMAP was designed at a time when mobile Internet apps did not exist, and when most Internet connections were dialup connections. As with mobile apps running on cellular networks, email clients of the time needed to make best use of the intermittent connection they had. Without going into too much detail, IMAP splits accessing an email account into several tasks:
- Logging in and retrieving a list of folders (inbox, outbox, etc)
- Retrieving a summary of messages within a folder, but not the messages themselves
- Retrieving an individual message and/or attachments
This approach enables the mail client to quickly find out what’s in a mailbox, and then retrieve the messages needed, without retransmitting information that is not needed or that has been sent before. This maps nicely to what many mobile apps do, and can be optimized in the same way.
In this paradigm, an information service presents an IMAP interface that email clients can connect to. Let’s use an upcoming event notification service as an example, and walk through the steps an IMAP client would use to display continuously updated event information tied to your current location. The client would go through the following steps:
- Login with the user’s credentials, request a list of folders. The server replies with a list of folders such as “San Francisco : Mission”, “San Francisco : Civic Center”, and so on.
- The client subscribes to some of all of these folders, and fetches a list of message headers. The message headers contain basic information about upcoming events. IMAP’s server side search function will also be a useful way to fetch customized result sets.
- The client fetches message bodies and attachments in the background, or when the
user opens an item, depending on how the email client is configured. - When the user opens a message, he or she sees an HTML formatted email, with links,
attachments, etc all preloaded, so there is usually no visible network delay because most of the message was preloaded in the background.
Why give IMAP a try?
Of course, you can do all of this with a native application that calls a web service in the background and selectively loads and caches information ahead of time. The problem is that it requires much more work on the part of the developer, and on some mobile platforms, background processes are tricky to manage (e.g. they’ll be shut down by the mobile OS to conserve memory or battery power), whereas using IMAP, one can simply subscribe to additional IMAP email account for the services the user is following. Most mobile email clients also notify the user of new or unread messages, and provide a simple notification mechanism, another bonus. Meanwhile, the service provider can track which users have read which messages, news items, etc.
Another advantage of using IMAP as a transport protocol, and using a built in IMAP agent on the phone, is it is already there, and is one of the core services on mobile devices. Your web app can behave like just another IMAP inbox the device can subscribe to, so it will be synced along with other mail accounts. Likewise, your users can subscribe using their phone’s built in mail client, or you can “skin” an existing client for look and feel, without forcing your developers to build the whole thing from scratch.
The missing piece.
Most of the pieces needed to do this are already available. The protocol is widely used and is built into nearly every mail app in some form. Only one piece is not widely available, an IMAP2HTTP utility that presents an IMAP interface to mobile apps, while communicating with an upstream web service via RESTful HTTP queries that are easy for web app developers to deal with.
Jesse Vincent’s Perl library, NET::IMAP::SERVER, enables web apps to serve data as IMAP mailboxes. In addition to libraries for popular programming languages, there is an opportunity for mobile development tools vendors, such as Titanium and PhoneGap to host IMAP-to-HTTP gateways that provide a solution for web app developers, much like the SMTP2WEB service enables web apps to process email. (Hint: it would also be nice if Google provided a similar handler for App Engine, much as it has done for inbound email processing and XMPP/Jabber messaging).
IMAP will primarily be useful for applications that continuously retrieve information, such as news readers, background search tools, and similar applications that can present information as a set of items in folders. It is a bit of a hack, but it’s a useful hack that can improve the user experience for many mobile applications. It won’t replace native apps, but will provide developers with a fast and inexpensive way to provide mobile access, and then make a decision about whether to invest in native apps further on in the product development cycle.
Brian McConnell is an entrepreneur, and the founder of the Worldwide Lexicon, an open source translation platform. Prior to founding WWL, he founded several telecom and mobile startups (where the balkanization of the mobile software industry was one of his biggest pet peeves).
Related content from GigaOM Pro (subscription req’d):
- Mobile Q1: All Eyes on Tablets, T-Mobile and ATT
- A Media Tablet Forecast, 2011 – 2015
- A Global Mobile Handset Platform Forecast, 2011 – 2015
Article source: GigOM http://feedproxy.google.com/~r/OmMalik/~3/8MAnQC0PsK4/