What is WAC and how it could help us

At Mobile World Congress 2011 in Barcelona, @uxebu attended the WAC event to catch up with the future of WAC.
WAC, short for Wholesale Applications Community, is a group of global mobile operators.
They provide, among other things, a spec for their correspondent web application runtime “WAC”.

Recently the new WAC 2.0 Spec got out and it’s looking good.
Compared to WAC 1.0, the WAC 2.0 Spec is a shift into the right direction:
Instead of inventing new APIs, WAC 2.0 adheres to web standards like HTML5 and W3C Widget Packaging.

Let’s compare the two major spec revisions in that repsect:

As said before, the WAC 1.0 Spec described distinct APIs, e.g., for audio, messaging (SMS & email), camera and geo-location.

Taking photos, for example, involved assigning a callback to a global value inside the Camera object and invoking Camera’s captureImage method.

There’s a problem with that: What if two pieces of code both assign their own callback to that shared value?
The one which assigned its callback last will be executed. The first callback is “dead code”.
Of course this can be remedied by the app developer, but I believe it’s the library’s job to get something as essential as deferred execution right.
All WAC 1.0 APIs use this global callback model and inherit the problem.
There are better, more elegant ways to defer execution (e.g. dojo’s Deferred or node’s callback passing & EventEmitter).
And fortunately, WAC 2.0 replaced the old model with a callback passing approach.

If everything goes well, what could WAC provide developers with?

1. An easy way to package web apps “for home screens & app stores” by wrapping web apps in native container apps.
2. An extension of browsers’ capabilities to enable richer web apps. This includes APIs for camera and file access.
3. In contrast to alternatives WAC has a strong focus on carrier network APIs. This could enable purchase through carrier billing.
4. A security model to effectively protect user’s privacy and security.

So go ahead and look at what the new WAC 2.0 has to offer.
I’m excited to build apps with it once it’s running on some major platforms!

To conclude I’d like to end this post with my personal opinion on what I believe WAC needs to focus on to succeed:

1. WAC runtimes have to run at least on iOS, Android and a few other major-marketshare platforms. There’s no point in developing cross-platform web apps if you ignore major platforms.
2. WAC’s marketing & identity need to be more developer-centric. Different top-notch WAC runtimes need to be advertised by WAC. Ideally there would be an official runtime for each platform.
3. Apps built on top of WAC runtimes have to be compatible to major app stores. For example, imagine a developer is targeting Android and iOS. What if Apple rejected WAC-based apps because of, e.g., a bundled custom WebKit build? I’m pretty sure no sane developer would consider WAC if that effectively banned their app from ever going into the most profitable app store. And while there will be carrier-operated stores I am not overly confident in that. Human beings simply prefer one familiar store/market on their phone.
4. Web app developers want their code base functioning consistently across multiple platforms with little or no effort. This implies that different WAC runtimes should strictly respect the specification. If there are implementation differences it’ll result in multiple code branches in the app code to repair broken implementations. Well, if WAC wants to succeed this must not become an issue for the app developer! Most apps are going to need custom code to support physical device differences. So hey, it will be incredibly helpful if the basic APIs were consistently implemented! Please don’t screw this up, because I somehow doubt someone would develop a cross-WAC-platform JavaScript framework.
5. WAC 2.0 runtimes with the above properties should appear very soon. They also need to be advertised in an easy to understand manner.
6. WAC should stick to W3C specs & drafts for APIs. If an API becomes part of a given platform it should be removed from that platform’s WAC runtime. Think back to when Google removed Gears support from their own browser to make way for standardized APIs.