Bruce Lawson's personal site

that would be nice and if possible it would be nice to include other people that go to the Web languages make their app. I’m thinking to Microsoft who seems to say one can develop applications in the next windows, or to television makers like samsung (I’m working on one those days), who has its own format of zip and .xml file.

You know, so badly named is the W3C’s Widgets spec that I assumed that it wasn’t at all the same thing as Chrome’s “apps”, and things of its ilk and so it got shuffled well into the depths of my “pay attention to, one day” pile.

I mean, I can sort of understand the rationale: for a while widgets and gadgets were the hot thing, and there’s a fair amount of commonality between what we think of as “widgets” and what we think of as HTML-based “apps”, but really, if you were to ask somebody what the spec would be called which describes the workings of installable applications built using Web technologies, “Widgets” would be pretty low down the list.

I would also like to understand why the W3C’s web application packaging format (“widgets”) was rejected by others. Was it primarily an XML versus JSON issue; was it mainly about NIH Syndrome; something else? If people have some feedback on this, please consider sending it to “public-webapps@w3.org”.

(BTW, I agree the title of the spec isn’t particularly descriptive and I take some blame for that. Bruce hints at Web Application Installation Format (WAIF) which is certainly more descriptive but “waif” itself is perhaps too disparaging. The group originally used Web Application Packaging Format but succumbed to marketing pressure to use “widget”.)

While I have little to say on this matter specifically as I know far too little about it, I can say you should ignore marketing if that’s the kind of crap they’ve pushed you into.

WAPF is both far more descriptive and far more useful than “widget” What’s the extensions for a Web Application Package Format? .wapf What’s the extension for a Widget? .wgt? .widg? .wdgt?

Never let marketing dictate the name of something engineers and coders are going to use. We’re from different worlds, and they don’t mix well. Marketing is all fluff, and frankly widget is utterly non descriptive, and doesn’t even conjour up the idea of an application or web technology. Horrid, possibly harmful, naming.

Regarding the putrescent name… I believe it comes from Opera! Robin Berjon and I tried to convince the original editor, Anne van Kesteren, to call it something else (we suggested WRAP: Web Resource Application Packaging), and I’ve since come up with many clever names (how does Local Applications for Web Standards, Offline and Networked, or LAWSON, strike you?), but a rose by any other name…

What is marginally more important than the name is widespread adoption and deployment. I totally agree that this is a real missed opportunity. There is a fundamental set of overlapping use cases for all of the browser vendors to work with, and good market reason for most of them to do so.

Certainly, mobile application developers and Web developers want this, and I’ve talked with big-name content creation companies, social networking sites, and mobile carriers that really want this to happen, so people can use a single universal app format for mobiles, tablets, desktops and laptops, and televisions. It seems that the only ones who haven’t wanted this to happen so far are the browser vendors and those invested in their own proprietary installable application market.

There have been some mistakes and missteps along the way, with Widgets, and some bruises. It may be that the whole Installable WebApps effort needs to be rebooted, learning what we can from Widgets, but getting as many of the right stakeholders at the table as possible to get quick consensus on the necessary features and functionality, with no preconceptions but with a predisposition to existing running code (and of course, with a rebranding). Speaking for myself, I would welcome any suggestion that will help get everyone on the same page.

I’ve always been curious as to why the widgets folks conflated the manifest (i.e., what’s important to the app) with the package (the zip file containing the actual assets). Doing it this way effectively puts all of that content off the web.

It also requires some duplication of effort / overlap with appcache; these things are way too similar. I.e., it’d be a lot more sensible if the appcache manifest were extended with configuration information, rather than reinventing it as a zipfile.

I see the utility of *sometimes* having an app package format as well (e.g, for distribution on a DVD), but why enforce the relationship? The manifest should define the app.

Anyway, I suspect that this confusion / overlap is hurting both appcache and widgets.

As Doug says, we’d initially proposed a much better name: WRAP! If we do v.next, we can certainly rebrand!

And if we do do v.next, then adding a JSON alternative to the configuration format really shouldn’t be that big a deal. We can split packaging and configuration as Mark suggests, in fact that’s been on the shopping list for a while. This also means splitting localisation for the configuration (where it’s good) and for the content (where it isn’t so hot). The good news is that even in the face of a large restructuring of the specification, a lot of the more bothersome parts of the work (e.g. figuring out what part of Zip and UTF-8 is interoperable) have already been done. So it’s not that much work.

Disclaimer: I don’t work on the relevant Mozilla subprojects. The following is my personal view.

The link to “Mozilla Install Manifest” points to a legacy RDF/XML format. It is an unfortunate artifact of Netscape dabbling with RDF ages ago. It’s probably not a good idea to use it as an indication of where things are going.

I think the W3C widget packaging has 3 problems:

1) It uses XML. Meh. Chrome and upcoming work at Mozilla use a JSON-based manifest. The manifest case seems like something where JSON is adequate and XML is needless complexity. I see the W3C strategy tax at work.

2) W3C widget packing reinvents jar signing using XML Signature. First, what’s the point of reinventing jar signing? Mozilla uses the jar signing mechanism (albeit with different crypto algorithms) for xpi signing. Second, XML Signature is just gratuitous complexity. XML Signature is one of those W3C specs that you shouldn’t depend on if you are aiming at deployment in the browser space instead of the enterprise boondoggle space. Again, W3C strategy tax at work.

3) It takes the app off the Web and stuffs it into a zip file. It would be more Webby to use the HTML5 app cache and make “installation” mean that the app is guaranteed to stay in the app cache and that the app can use as much cache space as it wants. (Note that developing for the app cache isn’t without problems, but it’s still more Webby than HTML/CSS/JS in a zip file.)

@Henri: Let’s assume all 3 of your points are right (Marcos’ disagreement aside). Is the relative severity of all of them enough to justify dividing the market?

1) XML vs. JSON: the manifest file is, what, 20, 30 lines long? The authoring experience of the manifest file is not much different, and no more difficult, than authoring HTML. This seems a minor quibble, at worst.

2) XML Signature versus jar signing: Or really, any other kind of signing, like OpenPGP or S/MIME. I’m no expert, but from what I recall, the profile of XML Dig Sig is relatively small and, though admittedly more complex because of the canonicalization issue, still not a huge implementation burden. Still, it could be better to go with some other signing mechanism that is scoped well to the problem and has stable off-the-shelf libraries that could be used. But even if we stuck with XML DIG Sig, it would be a relatively minor (albeit irritating) problem.

3) AppCache vs. Zip (also Zip vs. 7zip): There are use cases for both dynamically cached apps and static, persistent, locally installed apps (it’s more of a continuum, really). But even if both types of apps exist in one implementation (such as in Chrome), it’s still not much extra code, or much more for Web developers to learn (or authoring tools to manage).

By contrast, with the amount of market fragmentation around installable apps (I can think of at least 12 different “installable app” runtimes from 6 major companies, most of them with significant overlap), Web developers have to jump through flaming hoops just to reach half that many platforms. That doesn’t seem very “Webby”.

In other words, though the Widgets specs as they stand may have flaws (and I agree they could stand to have some changes, especially in v2), those flaws together are vastly less harmful, even in the long term, than the effect on developers and users from fragmentation.

The perfect is the enemy of the good. I think that there is now enough collective experience around installable apps among the browser vendors that y’all could come to the table and come up with a best-of-breed solution that’s good enough to satisfy the market need.

c69, you are missing the point of W3C widgets. It’s just a generic patent-unencumbered/open packaging format for various classes of application. A good example of usage is Opera: who use it to contain apps written with web technologies, for their extensions platform, as well as Opera Unite (iirc). So, it’s not about selling anything or making just one class of application. Lots of software is built because its is useful and not sold for money (e.g., PHP, Python, your web browser)… and a lot of it is open source… and a lot of that software is packaged in a Zip file. Sure, the web and widgets are missing a lot of APIs, but if widgets start getting traction, then we have a compelling reason to add those. Please try to be more incremental and forward thinking instead of dismissing the technology because it does not do what you want right now… HTML sucks compared to native apps, but it’s incremental improvements are constantly making things better (to the point where it becomes a serious threat to platforms like Flash). W3C Widgets make use of the Web platform and evolve with it.

(leaves my well worn employers hat at the table)

I think there are a few things here we need to think about carefully.

First of all the Widgets spec is mostly a packaging and configuration format. If I represented a mythical major software company that wanted to build a platform with installable apps based on HTML/CSS/JS, if packaging format was so important I had to make it vendor specific to create lock-in then, well I have major problems. Supporting Widgets is the easiest way to do a hat tip to the standards world, even if I’m only half serious. The value I can add to make my platform viable and of interest is always built on top of that layer, such as a beautiful easy to use UI, advanced APIs to make developers lives easier, monitisation, developer tools, cost, whatever. I can see no reason not to standardise on this layer, unless there are technical or marketing reasons not to.

On the marketing side there is the name. Widgets is confusing cause developers think of UI widgets (components, whatever) or that widgets are just little toy apps. If you are building a serious app platform, you probably don’t want the apps you want to take over the world being associated with little toy apps. You want them to be taken seriously as full blooded complex powerful applications.

The name come from Opera I guess, which in turn probably came from Dashboard Widgets and Konfabulator. It has out grown this. The easy solution is to rename. The hard part is to select a name, and the fact it breaks compatibility if you change the root element to a different element name. I would suggest for version 2 that there is enough political backlash to bite the bullet to do it. The implementation cost wont be too much. I’d suggest calling a spade a spade and calling the root element either manifest or app. As long as it isn’t widget.

The next issue is the technological one. I’m not sure what issues people have with the spec, but the likes of Mozilla and Google use JSON. I guess it is the big new trendy thing.I personally like XML but I guess we bite the bullet and support a JSON serialisation too. It at least makes it easy to manipulate with JavaScript if that is what you need. Things like RDF have multiple serialisations so it isn’t without precedence. It also reduces the reasons why vendors don’t use it.

There is talk in this thread about issues with XML Signatures. I don’t know enough about those, but we can take things one step at a time. Even if vendors adopt the manifest file but not the other parts it is still one step closer. I’m sure there is a solution for this and the gzip vs 7zip questions too. At least if we fix the major identified issues it becomes harder to justify why a supposedly open platform doesn’t support the W3C packaging format.

[…] the last few years, a number of misconceptions have been perpetuated about W3C Widgets. Over the next week, I will publish a number of post to […]

[…] 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 […]

[…] to solve similar problems secretly, and without discussion. This is why we have many formats for packaged/installable Web applications. Of course, each company promises that it will eventually standardise its solution to the problem, […]

[…] Lawson, a web evangelist for Opera, wishes the competitors would collaborate on one interoperable specification, and told me that the dozen or so proposed alternatives seem […]

[…] too. Instead of getting together and agreeing on one standard that works across browsers, there are numerous different packaging formats which force developers to choose their […]