Re: Inter-widget communication: next steps

Hi Scott, (I hope the e-mail goes through to the mailing list also)

On Wed, Dec 7, 2011 at 15:21, Scott Wilson
<scott.bradley.wilson@gmail.com>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:
>

I'd love to help out somehow, but I'm not quite sure I understand the
purpose of "refining what is meant by IWC"? So, what's the end goal the
group is trying to reach wrt IWC? Is it the definition of a single IWC
mechanism API, or multiple mechanism APIs, or just general IWC guidelines,
or something completely different?


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

I've always defined IWC as any kind of programmable data transfer between
any two widgets executing in a single browser or remote browsers. Under
this definition, models 1, 2, 3, 4, 5, and 7 would be considered IWC, while
6 wouldn't since HTML5 DnD isn't programmable in the sense that you can
program drag-and-drop actions (at least it wasn't possible when I last
checked). I consider all the use cases equally important and think that
both local and remote IWC should be allowed, as should different
communication models. For different application, different models of
communication will be more adequate.

Furthermore, considering any communication system as eligible for IWC may
seem a bit too broad, but this is our reality. I don't see a fundamental
difference between using a system like Faye over Twitter (each widget gets
its own Twitter account and can either broadcast, unicast, other widgets
can @follow, etc). One of the most interesting developments in this area
for me has been the WebRTC specification with its Peer-to-peer connection
API [1]. With a wrapper API, P2P connections could be used to achieve
direct cross-browser IWC communication similar to the postMessage API,
without any intermediary systems.

Best,
Ivan

[1]
http://dev.w3.org/2011/webrtc/editor/webrtc.html#peer-to-peer-connections