We have had a lot of discussions (and a few patches) related to inter-widget communication in Wookie also. I think the issue is selecting which of many potential implementations to go with. Shindig/OpenSocial would seem to favour using OpenAjax Hub pub/sub as the IWC mechanism, however there are a lot of alternatives, as Ivan Zuzak has explored in his work over several years now:
http://code.google.com/p/pmrpc/wiki/IWCProjects http://ivanzuzak.info/papers/2011_IWC_slides.pdf Combining both single-browser, single-user scope IWC and multi-browser, multi-user scope IWC with a single API is an interesting idea - is that what you mean by local and remote? Or is it just whether the messaging hub is located client or server-side, and the messages are all in a single-user, single-page scope? I think the main thing I've been struggling with for this (I'm also working on selecting the IWC mechanism for a telecoms project) is usability and user control - its one thing to allow the "Address Book" widget to talk to the "Credit Rating" widget, its another to give the user control of whether they think this should be allowed to happen. Another concern is hunting and cycling of messaging - e.g. A sends message to B, this triggers B -> C, which triggers C -> A... This would be an easy mistake for end-users to make when adding widgets to pages. (I've made this happen accidentally myself a few times while testing, resulting in the Spinning Pizza of Death in Safari) It would be good to have some common answers to these issues. S On 9 Aug 2011, at 18:42, Zhenhua (Gerald) Guo wrote: > Dominik, > We are also considering implementing inter-widget communication > framework in RAVE. Your work in ROLE is interesting and I will look > into it definitely. > > Gerald > > On Mon, Aug 8, 2011 at 1:56 AM, Dominik Renzel > <[email protected]> wrote: >> Dear all, >> >> this is indeed quite interesting. In the context of the ROLE project, we are >> developing an interwidget communication library that realizes both local and >> remote forms (local via HTML5 PostMessage, remote via XMPP PubSub) and uses >> the Google Android schema for intents as the event payload format. This >> works quite well, and was thought to enable communication between widgets >> and native Android applications in future... >> >> Best regards, >> >> Dominik >> >> >> Am 05.08.2011 15:44, schrieb Scott Wilson: >>> >>> On 5 Aug 2011, at 13:32, Ross Gardler wrote: >>> >>>> In addition to the article below there is an Apache licensed cross >>>> platform javascript library at >>>> https://github.com/PaulKinlan/webintents >>>> >>> This looks really interesting - though I'm not sure where the registry of >>> providers for each user lives? >>> >>> Paul and I have been working on a dynamic service binding mechanism for >>> widgets using a backend service registry and some selection logic - for >>> example for identifying which SMS sending API to use (e.g. direct through >>> phone device API, or via server-side SMS gateway). However, putting the user >>> in control of selecting providers for services may be a better idea, >>> especially if this takes off. >>> >>> I wonder if it removes the need for oAuth in some cases? >>> >>>> ---------- Forwarded message ---------- >>>> From: Steve Lee<[email protected]> >>>> Date: 5 August 2011 11:07 >>>> Subject: [raveincontext-dev] Google and Mozilla working on web intents >>>> To: [email protected] >>>> >>>> >>>> >>>> http://techcrunch.com/2011/08/04/google-announces-plans-to-bake-android-like-web-intents-into-chrome/ >>>> >>>> This should be really powerful for widget interactions >>>> >>>> Details: here >>>> >>>> http://webintents.org/ >>>> >>>> Steve >>>> >>>> >>>> >>>> -- >>>> Ross Gardler (@rgardler) >>>> Programme Leader (Open Development) >>>> OpenDirective http://opendirective.com >> >>
