RobinBerjon

Announcing Widgeon

It Quacks Like A Web Application

Tech, Essay |

There isn't much to W3C Widgets: you make a web site in the usual way with the usual suspects (HTML, SVG, CSS, JS...), you drop in a really simple config.xml file at the root, you zip the whole into a your-widget.wgt and — voilà! — you've made a widget. Welcome to the no-swearing, no-dark-incantations, no-unicorns-were-hurt-while-making-this-product approach to application development.

In a widget, you can do whatever you could do in a web context; and as APIs are added, you also become able to access and manipulate various aspects of the device on which the widget is running. In other words, we are building a complete application framework and this is the packaging bit.

Anyway, go ahead and use it, join the project if you're interested, and tell us what you think!

UPDATE: glazou asked for a widget with which to try the runtime, so here goes. It doesn't do anything useful at all, and may be scary for young children. In general if you have a web site you can zip, then you almost have a widget (at a minimum you simply put <widget xmlns='http://www.w3.org/ns/widgets'/> into a config.xml at the root and zip it up) — but expect more widget content coming soon.

Quack, quack, quack

It's all nice and well that W3C Widgets is becoming a standard, one still needs an implementation to do something useful with it. That's where Widgeon comes in. I'd been frustrated with the sluggish pace at which widget runtimes were being released, and somewhat annoyed that Mozilla didn't seem very interested in the space. It's fine for anyone not to be excited by any given new piece of technology, but in this case I think that this could make it possible for regular web hackers to build XULRunner application (something which is uselessly difficult today) that they could distribute around easily — more on this below.

So I rolled my sleeves up and built my own over the course of a couple weeks. Of that time probably a little over one day was spent writing the actual code, and a little under another was spent testing. An inordinate amount of time was spent on MDC and the web at large sifting through contradictory documentation. Hopefully the Widgeon project can help alleviate some of that aggravation.

But enough chatter. You can browse the project on Google Code, you can download it (Mac only at this time), or you can get the source (which has a build script for Linux, and all you need to run on Windows if you know how to use XULRunner).

This is an alpha release. I wouldn't recommend running widgets you haven't verified with it, even though normally they should be in a secure context. The UI needs a lot of polish but you can basically install and run widgets with it. It's released under an MIT license and patches are welcome. While I took on the initial effort, others have flocked to the project to help, notably Fabrice Desré (who just committed an extra layer of security as I write this), Dan Brickley, and Marcos Càceres.

A Widgeon is a type of duck — hence the quacking. The current logo reflects this, and was taken from the Open Clip Art Library.

The Widgeon engine was announced as the first to pass 100% of the test suites for the Widgets: Packaging and Configuration specification. It is also an implementation of Widget URIS.

Coming up

The first priority is to get it to look better, and be more usable. Right after that come support for the widget interface and for WARP. But that's plumbing, mostly interesting to standards buffs.

One thing that we want to add is lots and lots of APIs to do lots and lots of stuff. Ideas include XMPP, IRC, file system, the DAP APIs of course, streaming, micro-blogging, and whatever other stuff piques our fancy. We are deliberately considering that until we've reached 1.0 at least this is a platform for wild experimentation — things may break, but at least they'll be there.

Another aspect is development, and it is two-fold. One part is just creating and debugging widgets through Widgeon (by being able to point it to a directory instead of just to a package, making FireBug available, providing a UI to create configuration documents, saving to widget packages, etc.). The other part is more ambitious: there is no reason why widgets couldn't be saved as self-executable and redistributable applications, atop XULRunner. This would effectively hide away all the nastiness there is in having to use XULRunner directly while exposing all of its power. We could (easily) provide an option for chrome-security level widgets, and (equally easily) support XUL as part of the accepted document type (actually, we probably already do with <content src='your-xul.xul'/>).