Scott, answers and comments inline...
Am 10.08.2011 11:25, schrieb Scott Wilson:
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.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'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.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?
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.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)
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.
It would be good to have some common answers to these issues.
I'd be glad to be part of the discussion!
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/webintentsThis 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
