Re: Inter-widget communication: next steps

Hi Scott,

On Wednesday, December 7, 2011 at 2:21 PM, Scott Wilson wrote:

> 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:
Sorry it's taking time to respond (and sorry for the top-post!). The collection of information/use cases ([1]) is great, but it's very extensive and I'm trying to digest it as quickly as possible.  
>  
> 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.

Agreed.   
> 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.
I also agree. I think the problem is what you outline and that there are a whole range of existing solutions to this problem of inter-widget communication.   
>  
> 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.
>  
> Thoughts?
I don't have enough (practical or theoretical) knowledge of a lot the stuff in the references below to make a very educated comment. The question that I keep asking myself is:  

* Where is it broken (with respect to 1-7 above)? I see you list a whole bunch of things that seem to be working for certain applications types.  
* What could be improved? certainly, intents would make things a lot better and easier to work with… hopefully, if they come up with some clean API and markup.

> - 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


--  
Marcos Caceres

Received on Monday, 12 December 2011 18:56:03 UTC