incubator-wookie-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Renzel <ren...@dbis.rwth-aachen.de>
Subject Re: Google and Mozilla working on web intents
Date Wed, 10 Aug 2011 15:07:00 GMT
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.
> 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.
>
> 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
>> <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
>>>


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message