During the past couple of weeks I have been (together with some other colleagues at Igalia) checking the different solutions that the main actors in the ‘open web’ are proposing to enable the local installation of web apps and the interaction with the underlying platform or device, in some cases going beyond the standard HTML5 interfaces.
I will try to give here a high level overview of the alternatives and also provide a few links that can be useful for those interested in the topic.
- W3C
In 2006, the W3C started to work in the definition of W3C Widgets. Despite what the name may suggest, those ‘widgets’ are actually complete apps developed using HTML5 technologies (HTML/CSS/JavaScript), packaged as compressed files, which include an XML manifest with metainformation. You can read a more detailed explanation about what ‘widgets’ are and what they are not in this series of blog posts published recently in the W3C community pages.
Three years later, in 2009, the W3C started to work on another complementary standard called DAP (Device API), an extension of the HTML5 APIs that would allow a more complete access from DAP enabled apps to the system where they are running, including interactions with battery, camera, contacts, basic messaging, network, vibrator, sensor and calendar.
These two standards were used by some third parties, sometimes partially modifying them, and in other cases taking them as inspiration for pretty different and incompatible solutions (leading to a well known situation). We will see now the main alternatives that have appeared during the past couple of years.
- WAC
At Mobile World Congress 2010, in Barcelona, 24 major operators announced WAC (Wholesale Applications Community), an industry consortium to create an open platform for developing and distributing HTML5-based mobile apps.
WAC defines APIs for interaction with the device’s camera, contacts, calendar, tasks, messaging (basic), accelerometer, device status, filesystem, device interaction (lights, vibration), orientation, geolocation. They are similar but not totally compatible with W3C APIs. There is a multiplatform SDK based on Eclipse and the Android emulator which automates the process of creating the package with the XML manifest and the HTML/JS/CSS files, and testing it.
The consortium is currently working on the 3.0 release of the WAC API spec, which according to the (lack of) information available in their webpage is being defined privately, making participation of those external to the consortium extremely difficult. Also, the channel for application distribution is proprietary, so although WAC is based on open standards, the solution is quite closed and seems not attractive for open source projects.
- Chrome
A bit later, still in 2010, at the same time they announced the Chrome web store, Google defined two possibilities in order to install web apps in the browser: hosted apps and packaged apps.
Hosted apps are a classical webpage which provides a JSON manifest (similar to the one that had been defined for the W3C widgets) including the launch URL, basic data, autoupdate settings, permission for accessing each of the standard HTML5, and a few other bits. Providing the manifest enables easier installation and
simplifies and speeds up a bit the opening of the webpage, but that’s all.
Packaged apps go a step beyond. They are webapps that are bundled into a .crx file (a Zip file, same format used for Chrome extensions), they can use most of the Chrome extension API (only the creation of page actions and browser actions are not allowed), and are limited to 10MB of total size. Packaged apps include the same kind of manifest than hosted apps (this time describing also permissions for accessing the Chrome extension API modules), so they are similar to (but incompatible with) the W3C Widgets. There are various reasons why this kind of apps make more sense than a hosted app for some use cases.
It is worth noticing, for those less familiar with the terms, that packaged apps, although they use the Chrome extension API, are something totally different. Extensions don’t have their own UI and are complementing the behaviour of the browser, typically for all the webpages, while packaged apps are actual web apps with their own UI, that are designed to run locally. There are instructions available which clarify when hosted apps, extensions and packaged apps are typically used.
Although Google’s proposals are well documented, they seem to be clearly targeting their own app store, and not the open web. There is not a description of how somebody could install Chrome web applications from their own webpage.
As far as I know, Google hasn’t defined a solution similar to DAP’s or WAC’s device APIs so far, so their proposal for device interaction would be to use just standard HTML5 interfaces.
- Mozilla
More recently, in February 2011, Mozilla announced that they were working on what they call Open Web Apps. The idea is pretty similar to W3C’s Widgets and Chrome’s hosted apps: ordinary web apps plus a JSON manifest with very similar but yet again slightly incompatible fields. The main two additions are a ‘widget’ field where you can point to an HTML file that would be a simplified version of your standard UI, and a few well documented hooks in order to enable the creation of app stores not controlled by Mozilla (e.g. navigator.mozApps.install, navigator.mozApps.amInstalled JavaScript functions).
Even more recently, in August 2011, they announced WebAPI, an extended HTML5 API specially designed for phones, similar to W3C’s DAP and WAC, but again not compatible. WebAPI includes APIs for telephony&messaging, contacts, battery, contacts, camera, filesystem, device status, settings, accelerometer, mouse lock, vibrator, and more. Although the work has just started, there are already some examples of applications working on Android using some bits of WebAPI.
This comment in Mozilla’s bugzilla is relevant if you are trying to understand why they are not considering using WAC’s APIs directly. And this email to one W3C mailing list is relevant to understand why they didn’t use W3C’s DAP either.
As far as I know, Mozilla doesn’t have the equivalent to Chrome’s packaged apps, or ‘W3C Widgets’, and they are focusing the work more on open web apps and the extended device APIs.
- Summary
The W3C, Google, Mozilla, WAC and others have been working for the past three years on defining proposals for the installation of web apps and the interaction with the underlying system/device from them. Although unfortunately the situation is quite fragmented, given that the solutions are quite similar, it is possible to imagine a convergence in the near future, that would benefit (almost) everybody. There have been already positive statements by some of the key players.
4 thoughts on “Open web apps and device APIs”