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.

10 years of igalia

As you probably have noticed via other sources, this month we are celebrating something very significant for us at igalia: we, the company, the project, the collective, are becoming 10 years old.

It has been an amazingly intense experience. 10 years is a lot of time, and for those of us who have been here since the very beginning, born close to the end of the 70s, it means that about 1/3 of our life, and therefore almost all our adulthood, was professionally devoted to contribute to the construction and evolution of igalia.

Although many things were discussed along several meetings during the first half of 2001, when we started defining our founding principles, two were clearly identified as the pillars of the project:

  • We wanted to develop free software, to participate in the amazing, international network of cooperation where people were then starting to explore new paths towards open innovation. Using and supporting free software, the most common business models back then (and arguably still now) was nice, but we wanted to go further and to humbly devote most of our energy to build new -and to contribute to already existent- software.
  • We wanted to bring direct democracy to the working place, embracing a cooperative internal structure, sharing ownership and making all the members of the project participate in the discussions and decisions that define the future of the company.

Looking back, I honestly think that we did a good job respecting those founding principles. Both us (individually and collectively) and our environment have changed a lot over the years, we have gone from a small local team of people to a much bigger and international team composed by colleagues with many nationalities working from many different locations; we have gone from small and local customers to working internationally with most of the relevant actors which are using or contributing to the different open source platforms/projects; we have gone from being relatively inexperienced but passionate and willing to learn to equally passionate but with already some experiences to learn from; and all this time, without exceptions, the essence has remained untouched: the spirit was the same all the time, and we still do free software, and we still believe in people and keep the flat internal structure.

It is quite difficult for me to write this post. Many memories and feelings cross my head, many good moments and also some more complicated ones, mainly in the first period, when a huge percentage of companies disappear and we managed to resist, learn and grow. If I wanted to be fair I would need to thank here a lot of people, a very big list, all those who in one way or another were part of this project, for all the help and support along the years, but they already know who they are and how grateful I am, so I will keep it private, and just say that I am very proud of what we have achieved:  10 years participating in the free (software) world.

Everything ready for the WebKitGTK+ Hackfest

During the past weeks, Xan and myself have been busy putting together everything for the WebKitGTK+ Hackfest, which will take place next week at Igalia‘s offices in the beautiful city of Corunna.

The original idea for this event arose a few months ago. We have a team of Igalians working full-time, together with other members of the community, in completing and improving GNOME’s WebKit port, and we thought that it would be a good idea to propose ourselves to host a hackfest, which should turn out to be very productive for the project. After talking to the Foundation and all the core developers, we got such a positive feedback, that we decided to push it forward.

So we will have here all the most active WebKitGTK+ hackers, working together, in the same place, during 1 week (15th-21st of December), to make one of the (imho) most important components of our platform rock even more.

The hackfest is sponsored by Collabora and Igalia, and has the support of the GNOME Foundation, which covers about half of the total cost. Igalia will also take care of food&drinks for all the days, and will organize a nice dinner before the end of the event, so that people don’t leave the place without enjoying the famous local food. Of course, any last minute extra sponsor would be very welcome. So if your company cares about WebKit in GNOME, it is the right time to join and contribute.

Stay tunned, I will try to blog and tweet about the event as much as possible.

SCIGen: the art of generating research articles

SCIgen is a program that generates random Computer Science research papers, including graphs, figures, and citations. It uses a hand-written context-free grammar to form all elements of the papers. Our aim here is to maximize amusement, rather
than coherence.”

Pretty impressive what they manage to do. One of the goals is to be able to find out conferences where they have very low submission standards. They even have some examples of articles submitted.

Let SCIGen improve your CV!

Women, Computer Science and Free Software

I’ve been quite interested lately in the topic, and decided to post here a collection of related documents and links:

Audioscrobbler and MusicBrainz

I’ve been playing during the last week with these two very cool projects.

Audioscrobbler keeps a database with the music profiles of the registered users, based in the messages sent by plugins of the media players (there are plugins for a long list of players) when the users plays a song. Based on this, Audioscrobbler creates statistics, generates recommendations, and creates a network of people where the connections depend on the musical taste.

MusicBrainz is a music metadatabase with information about the names of the artists, the names of their albums and the concrete list of tracks included in each of the albums. But the very interesting concept is that the keys in the database are based on the physical characteristics of the audio CD, or the MP3 and Ogg Vorbis files. Any music player, using the provided API, can obtain metainformation on a concrete song, and use it for tagging. And it works!