Scott's Workblog

scott.bradley.wilson@gmail.com


attention!
This blog has moved! Go to my new blog!


June 01, 2009

Google Wave Widgets: Implementation using W3C Widgets and Wookie Server

Unless you're living in a cave somewhere you've probably heard about Google Wave. (There's a good post by Wilbert Kraan here, and another by Michael Feldstein here). What you probably haven't been able to do is see some of it in action. However, over the weekend I implemented the Wave Gadget API for W3C Widgets using our Wookie Widget engine, so you can see some of the widgets in action.

Google Wave is actually several discrete components. On the one hand you have the Wave Server, which is basically a Jabber instant messaging service with some extensions. Then you have the Wave Client, which is a bit like a web-based IM client with bells and whistles. And finally you have the application that lets you use contextualized collaborative applications that can update in real time - the Wave Gadget Server.

Now I don't have a Wave Server or Wave Client to hand, but we have been fortunate enough to have already developed a Widget Server (Wookie) that already has the functionality described in the Google Wave Gadgets API, which is shared state and participant information. So implementing the Google Wave Gadget API was quite simple, and mostly involved mapping the API calls to our existing APIs and web services.

In Wookie we primarily support the W3C Widgets specification rather than Google Gadgets, so I converted the Google Wave Sample Applications to W3C Widget format. This is quite simple in practice - I remove the proprietary Google markup to make the pages regular HTML5, create a W3C Widgets "config.xml" file for the widget metadata, and then zip it up and change the extension to ".wgt".

Once "de-googled", the Widgets need to run in a Wave Container - that is, an application which manages participants and can have a shared state context, and can then communicate this with the Widget. We already do this in Wookie by creating plugins for different web applications; the plugin enables the web app (e.g. Moodle) to ask Wookie for a Widget for a given person in a given context (such as a course or a user profile page - in Moodle we use the Block identifier). The result is something like this:

Screenshot showing Wave-enabled widgets running in Moodle

However, we can also run some of these sample applications in "anonymous" environments if they don't need participant information. So, below I've included the "fridge magnet poetry" Wave Gadget example. If you move the "magnets" around, this is synched with the view of everyone else reading this post (so you may see them moving about by themselves if you're viewing this at a busy time of day). You can also check it out if you open this post in two different browsers. (NOTE: As this is running on a Wookie development server using prototype code there may be some latency and the odd bug. It also hasn't been tested on anything other than Safari4beta and Firefox)

By itself this is not a very exciting example, as most of the cooler examples need a participants model, and so lend themselves better to running in something like Elgg or Moodle than a plain blog site like mine. However the basic principle is that Widgets with this level of interaction could easily replace LMS-specific tools in the near future.

You can now download and run your own Wookie server that can run Wave gadgets (suitably converted to W3C format as above) - you need MySQL and Tomcat, and a bit of patience in setting it all up. You also need to either download our Moodle Block plugin for a Moodle installation, or write a plugin for your favourite web container to try them out in.

main archive