Gmail And HTML 5
If you accessed Gmail today on your iPhone or Android based phone using a web browser, you will have noticed some differences. It has a few more bells and whistles but of particular interest is the addition of offline access. Gmail went offline a few months ago thanks to Gears (formerly Google Gears). Mobile Safari on the iPhone doesn't however have a Gears plugin, so how was this accomplished? The answer lies in the yet to be finalized HTML 5 specification and specifically the client-side database storage functionality that it calls for. While HTML 5 remains a work in progress, WebKit based browsers, such as Safari and Mobile Safari have already adopted database storage. This permits developers to create and subsequently read from/write to a fully capable, locally stored, relational database which is accessed via the web browser. I view today's Gmail release as a watershed moment for offline web applications as this is the first mainstream web application that I've seen using the technology.
I view offline access as an inevitable next step for web applications. We have continued to blur the line between desktop applications and their web based counterparts. Technologies such as AJAX, Flash, Silverlight, etc. have continued to push the limits on what browser based applications are capable of but despite all of the added functionality, web apps suffer from one inherent limitation - they disappear when you go off the grid. Well, that's about to change.
Local Gmail Storage
Since the iPhone (un-jailbroken) doesn't permit raw file access, I'll walk through Gmail's use of HTML 5 via Safari on a standard OS X platform. First off, in order to get Google to deliver the HTML 5 version of Gmail, we'll change the User-Agent header to match that used by the iPhone as follows:
Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_2_1 like Mac OS X; en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1 Mobile/5H11 Safari/525.20
Now when we visit Gmail, the iPhone version of the app is displayed. At this point, local database storage has automagically been setup. One concern that I have here is that the end user is not informed of this. Gears will at least require the end user to acknowledge that a local copy of data is being set up. While I'm not a fan of leaving security decisions in the hands of the average end user, I do feel that users should be informed that they're now carrying around a local copy of their email, which could be accessible if their phone were ever lost.
Now let's see exactly what has been stored locally. On OS X, the database is set up in the following location:
Separate databases will be established for each separate Gmail account accessed, with each receiving an incremented numerical value. The database leverages the SQLite format. As such, database content can be viewed with an application such as the SQLite Database Browser. Below are details the tables that are created, along with a description of the data contained within:
- action_queue - Purpose unclear
- cached_contacts - Top 20 contacts, including email addresses and names
- cached_conversation_headers - Abbreviated content from email messages including the full subject, sender's name and first sentence or two of the message
- cached_labels - User defined labels which can be assigned to email messages
- cached_messages - Similar to cached_conversation_headers
- cached_queries - Purpose unclear
- config_table - Application version number
- hit_to_data - Purpose unclear
- log_store - Purpose unclear
Overall, I feel that the HTML 5 specification has a great deal to offer and it's encouraging to see some early adoption. It will be up to developers to ensure that powerful features such as local database storage do not unnecessarily expose end users to increased risk.