One of the common feature requests and extensions developed for Apache Wookie is the facility to let widgets talk to one another, something that tends to be called inter-widget communication (IWC). I’m now involved with two EU projects (ITEC and OMELETTE) both of which would like an IWC solution. So what should I go for?

Luckily, there is a lot of prior research to go on. Though to be honest, the breadth of options has given me a bit of analysis paralysis.

Perhaps the most complete reference on IWC is Ivan Zuzak’s list of systems for inter-window communication, which provides a comprehensive overview of IWC projects and protocols. Ivan looked at everything from basic messaging between browser windows to publish-subscribe hubs and analysed their capabilities.

The first demo I saw of IWC was of something developed under the PALETTE project, and is described in a paper by Sire, Pacquier, Vagner and Bogaerts entitled A Messaging API for Inter-Widgets Communication. This actually describes two IWC mechanisms – a publish-subscribe model, and a drag-and-drop model layered on top of it. In PALETTE, you had both listeners and events for automatic messaging, and you could also have elements that could be dragged and dropped between Widgets. (This was before HTML5 drag-and-drop). The pubsub model worked in a rather Java-like way with “addEventListener” and “fireEvent” methods.

Perhaps one of the most fun examples I’ve come across is one created by Tobias Nelkner called “Snap” that shares information between widgets based on proximity – there is a nice demo of this embedded in his slides. The team at Paderborn seem to have been quietly making a lot of progress in this area; the best place to find out more would seem to be Tobias’ YouTube Channel.

An alternative approach I’ve seen quite often is a kind of “wiring diagram”, where the user or designer wires together the Widgets with some sort of messaging channel that is then executed by the platform. Examples include Websphere’s mashup editor or the EzWeb project. There is something quite appealing to the engineer in me about wiring stuff together visually, but I don’t think its necessarily a good model for most users. I think in particular having to design the interactions between widgets beforehand is a bit limiting – it would be much nicer to just drop a widget into a space and see things start happening!

So that really puts me in the publish-subscribe camp. However even there, there are a lot of options to go for – Ivan’s table has six of them! Also, the ones in that table are mostly applicable to a single window (or a single user) – what if I’d like a widget to send a message that could be heard by widgets being viewed by other users in the same workspace?

After a lot of dithering I think I now have a basic idea of what to do – dither! Or at least, dither in a more productive fashion by making use of my explorations of dynamic binding in JavaScript. If I have a very simple API that I can expose to Widgets, I can defer the choice of actual mechanism used to deliver the messages depending on the requirements and how each option performs.

At a scripting level, nearly all pub-sub mechanisms work in the same way, with only two basic methods: publishing a message to a named topic, and subscribing to a named topic and firing incoming messages at callback functions.

So this is quite simple; I just have an API in JavaScript which looks like this:

publish(topic, message)
subscribe(topic, callback)

OK, there are more complex pubsub interfaces, but this is a pretty common pattern and can get me a bit further. I then need to use my handy dynamic loading script and viola:

I hooked the implementation up to the Faye pubsub server on Node to try it out, by exporting the Faye client functions using my simple pubsub API, and it worked a charm. Faye really is a very nice pubsub solution.

I can now substitute other pubsub implementations for Faye to try out different ways of handling the messaging, for example limiting the scope of messages to a single context, to a single user, or broadening out for global messages to all Widgets. I can look at cloud-based pubsub services like Pusher, standalone services like Juggernaut or Apache ActiveMQ, or solutions built into Wookie itself. I can also look at things like proximity-based or wiring-based restrictions as a separate concern.

2 Responses to Inter-widget communication

Have you tried IWC with using the Ozone Widget Framework in IE7 only? Our customer refuses to upgrade from IE7 and as such Java script runs very slowly. When using IE7 with the OWF the IWC seams to break as timeouts occur between IE7 events and IWC events between widgets. Got any ideas on how to correct this?