incubator-wookie-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Wilson <scott.bradley.wil...@gmail.com>
Subject Re: Google and Mozilla working on web intents
Date Wed, 10 Aug 2011 15:35:43 GMT
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
>>> <renzel@dbis.rwth-aachen.de>  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<slee@opendirective.com>
>>>>>> Date: 5 August 2011 11:07
>>>>>> Subject: [raveincontext-dev] Google and Mozilla working on web intents
>>>>>> To: raveincontext-dev@googlegroups.com
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 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>


Mime
View raw message