WebKitGTK+ hackfest wrap up

After more than 5 days of hacking, discussions and some social activities, the 3rd edition of the WebKitGTK+ hackfest, which took place at the Igalia office in A Coruña, is coming to its end. We are about to go for dinner and most people are leaving tomorrow early in the morning, so it is time  for wrapping up.

WebKitGTK+ 2011 Hackfest

In my opinion the hackfest has been a success both in terms of technical progress and consolidating a common vision within the team about the way forward both for WebKitGTK+ and Epiphany. The intense work we have been doing during the past 2 years has given its results, and unlike the previous two editions in 2009 and 2010, the topics defined in the agenda this time were not mainly about fixing critical and blocker bugs and implementing basic missing features, but about more ambitious and challenging goals, aiming to make WebKitGTK+ and Epiphany rock.

Examples of this are the progress achieved this week in several areas, including the Epiphany improvements & new design, a consolidated WebKit2 API (which will improve the performance and stability once used by the browsers and embedders), accelerated compositing support, improved HTML5 video support, better accessibility support, JSC improvements, HTML5 notifications, HTML5 history, better networking, new and more updated bots for the continuous integration, or developer documentation.

Besides taking care of many of the organizational bits, my contributions were focused on participating in the discussions about the new Epiphany UI and mainly on the integration of open web apps and HTML5 technologies within GNOME. I will be blogging very soon about how we see this integration happening and the initial proofs of concept that we have already started to implement.

WebKitGTK+ 2011 Hackfest

Finally, I would like to thank our sponsors (Collabora, Motorola and Igalia) and mainly the GNOME Foundation for their contributions. Without this support, getting together 20 hackers in the same room, taking care of them, and enabling all the progress we have had during the week would have been impossible.

Open web apps and device APIs

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.

Announcing the WebKitGTK+ hackfest 2011

For the third year in a row, by the end of this month (29th of November – 5th of December) we will be hosting at the igalia office in A Coruña a new edition of the WebKitGTK+ hackfest.

WebKitGTK+ 2010 Hackfest

About 20 GNOME and WebKit hackers will be working in the same place for a week on topics related to WebKitGTK+, Epiphany, JavaScriptCore, accelerated compositing, networking, accessibility, multimedia, GNOME Shell browser integration, web technologies for GNOME apps, and more.

The event is possible thanks to the invaluable support of the GNOME Foundation, being both Collabora and Igalia official sponsors.

The hackfest was a total success in previous years, and we have even higher expectations for this edition. We will blog during the week about the plans and achievements, so stay tuned.