W3C home > Mailing lists > Public > public-native-web-apps@w3.org > December 2011

Inter-widget communication: next steps

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Wed, 7 Dec 2011 14:21:50 +0000
Message-Id: <9FC7FCF7-B557-4298-9ACB-C1BFCC4EAA27@gmail.com>
To: public-native-web-apps@w3.org
Hi everyone,

We've collected use cases from a lot of people[1] but perhaps need to refine what we mean by inter-widget communication. So far we have a range of possible models:

1. Local (same user agent, different widgets) broadcasting of messages using PostMessage
2. Local publish-subscribe messaging using OpenAjax Hub, PostMessage or similar
3. Remote broadcast messaging using Comet, XMPP or similar
4. Remote publish-subscribe messaging using Comet, XMPP or similar
5. Remote shared state synchronisation using Comet, WebSockets or similar
6. Local drag and drop between widgets embedded in the same workspace
7. Local invocation of methods in one widget from another (RPC-style or intents-style)

While these can all be considered "inter-widget communication" they are quite diverse approaches.

Here are a few ideas to whittle down the options to something a bit more manageable:

- the DnD use cases can already be realised using the existing HTML5 DnD spec [2] and should be dropped.
- the RPC-style cases could, for the most part, be realised using Web Intents [3] and the UCs should be recast as requirements to feed into the Web Intents task force.

This would then reduce the scope to broadcast messaging, publish-subscribe messaging and state synchronisation.

Personally I'm most familiar with state synchronisation, as the Google Wave Gadget API state model [4] is something we use a lot in Apache Wookie (and is obviously in Apache Wave too). I'm not sure if we want to progress that towards standardisation given it relies on a lot of other pieces in the environment (shared context, server-side operational transform etc) so may be too high up the stack for a W3C spec. Its probably also something we'd want to check with the Federated Social Web folks as there is overlap there.

Pub-sub is pretty common, though as with the above, it usually relies on a messaging infrastructure for handling topic subscriptions such as RabbitMQ, QPid, Faye etc., so again may be a bit high up the application stack.

Other projects have been using broadcast models such as the Open App [5] API. The Broadcast approach also seems to have some similarities to Web Intents, though the actions are mostly passive, such as "select", "unselect" etc. Looking through the UCs in the document Erik pointed to [6] I see some scenarios that would also be covered by Web Intents, while the rest seem to be about sharing contextual awareness of the user  - which news item they are reading, which location they have selected on the map etc. There are definitely some issues to work out here like privacy and security considerations, but may be the best place to start.

Alternatively, we may instead aim towards developing a Note that points widget developers towards the most appropriate existing specs and implementations.


- S

[1] https://docs.google.com/document/pub?id=1aUScFats9A0zBUqNbkw9J2XhmupKfA38eU0wYjs81FM
[2] http://dev.w3.org/html5/spec/dnd.html
[3] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0000.html
[4] http://code.google.com/apis/wave/extensions/gadgets/guide.html#state
[5] http://sourceforge.net/apps/mediawiki/role-project/index.php?title=Library:Open_Application
[6] http://ceur-ws.org/Vol-638/isaksson_mupple10.pdf
Received on Wednesday, 7 December 2011 14:22:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:46:09 UTC