On 10 Aug 2011, at 16:07, Dominik Renzel wrote: > Scott, > > answers and comments inline... > > Am 10.08.2011 11:25, schrieb Scott Wilson: >> 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 > It would be interesting to know why you favored OpenAjax Hub. Some of my > project partners should be interested to discuss this, since they did the > local IWC part.
I don't particularly favour it myself, but its in the OpenSocial specification and has been implemented in Shindig, so I kind of treat it as a default. >> 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? > It's the combination you mentioned first. One local messaging hub per > browser, one server-side messaging hub (node in XMPP PubSub terminology) for > multiple users; an XMPP-enabled proxy widget forwards messages from remote > entities to the local hub, which again forwards remote messages to subscribed > local widgets. >> >> 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. > Yes, I totally agree here. Moreover, if you come to the case with multiple > users, it is also the question if user A is willing to process events coming > in from a potentially malicious user B he does not know and trust. We tried > to approach this problem with introducing trust values for each user's XMPP > roster list contact and a trust threshold configurable per user. Each user > can assign trust values to all his contacts. For yet unknown people a trust > value can be inferred following Golbeck's TidalTrust algorithm. If the trust > value of user A towards user B is below A's trust threshold, the event is > discarded upon arrival. We are currently evaluating this approach. Great, I'm glad you're looking into this. I was also favouring providing the user with information prompts along the lines of "widget x wants to share information about topic y with widget z" as a way of explicitly letting users allow or disallow IWC connections, a bit like geolocation. >> >> 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) > Same thing happened to me as well... > > And at least for the multi-browser, multi-user part, there is another > question of context. Concretely, multiple parties would have to have a common > context in which they work together, for example a chat room, a widget space, > a Google Wave, etc., from which a Jabber ID for the PubSub node can be > automatically derived. Or they would have to negotiate the Jabber ID of the > Publish-Subscribe node they use for remote event exchange, which is not quite > user friendly. This of course makes the whole thing more complex than the > single-user, single-browser variant. We have discussed various options in our > project. Wookie uses the "shareddatakey" as the context identifier, and for Rave we have the concept of "spaces" which is pretty analogous. So this provides a context identifier which can be used for a pubsub context - e.g. as a namespace prefix onto a topic (e.g. using Faye) >> >> It would be good to have some common answers to these issues. > I'd be glad to be part of the discussion! :-D > > Best regards, > > Dominik >> >> 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 >>>> > > <renzel.vcf>
