rave-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: ROLE IWC for Rave
Date Tue, 15 Jan 2013 10:53:23 GMT
Hi all,

@Chris: That is correct. It's cross-browser pubsub, realized with XMPP.
@Jack: If you want to try it, you can have a look at a running demo on 
the ROLE Sandbox: http://role-sandbox.eu/spaces/iwc. What you basically 
need for testing are two open browser instances and two Google accounts 
to sign in as different people. For each of the users sign in with their 
respective Google account and join the respective space (spaces are 
similar to pages; cf. OpenSocial spaces) to become a member (after 
having joined you *might* need to reload...). In the ROLE Sandbox, IWC 
messages are only transmitted, if the respective user is member of that 
space. However, other access models are imaginable, when we think about 
the page concept in Rave. Once signed in and being member of the space, 
you can play around with the three tech demo example widgets 
(Collaborative Painting, navigation on a map, video navigation (select 
video, publish seek). If you are interested in even more widgets using 
ROLE IWC, there are a couple of examples available in the ROLE Widget 
Store. We could give you some pointers...

Dominik

Am 15.01.2013 04:22, schrieb Chris Geer:
> On Mon, Jan 14, 2013 at 7:00 PM, Jack Weaver <weaver.jack@gmail.com> wrote:
>
>> Would this provide an in-session IWC?  Or is this cross-session IWC such
>> that all instances of the widget(s) get the pub/sub message?  It looks like
>> cross-session messaging but I wanted to ask first =)
>>
> I assume by "in-session pub/sub" you mean between widgets on one page? That
> is already provided by the shindig pubsub2 feature. It sounds like this
> will extend that library to provide cross-browser pubsub.
>
>
>> I've used portal frameworks before (one of them, Ozone Widget Framework
>> here:  https://github.com/ozoneplatform/owf) where IWC is in-session only.
>>   This provided app developers some pain such that they had to implement
>> their own pub/sub so messages would be received between multiple apps
>> running across different sessions (one such way is to use Atmosphere, here:
>>   https://github.com/Atmosphere/atmosphere).  If you do this Andreas, I'd
>> love to test it out.
>>
>> ---
>> Jack Weaver
>> http://jackweaver.net/
>> 661/349-8778
>> PGP: 6B9C 40C2 1408 97F2 2588
>>       93EC E924 F32C 8AA4 6955
>>
>>
>> On Sun, Jan 13, 2013 at 8:34 PM, Andreas Guth
>> <andreas.guth@rwth-aachen.de>wrote:
>>
>>> Hi,
>>>
>>> I'm a developer for the ROLE project [0]. In the project we also use
>>> OpenSocial widgets and a fair amount of Rave code and have created a
>>> system that makes inter-widget-communication work over multiple
>>> machines that we'd (finally) like to contribute to the Rave project,
>>> in particular referring to Rave Epic 25 [1].
>>>
>>> Dominik Renzel and Sten Govaerts presented and demoed ROLE
>>> Inter-widget Communication as it is realized in the project's
>>> prototype of a widget based personal learning environment during last
>>> year's Apache Rave Hackathon in Utrecht and were encouraged to move
>>> forward in developing a respective patch. Their slidedeck ([2];
>>> starting from slide 6; slide 14 containing a set of links pointing to
>>> further materials, code samples, demos, etc.) gives an overview of we
>>> did it in ROLE and how developers could use a respective widget API
>>> (notice that this is not restricted to OpenSocial). We hope this is
>>> still of interest for Rave, since I am currently preparing such a
>>> patch.
>>>
>>>
>>> I already looked through the source and began to port some of our code
>>> but I may need some pointers as to where the IWC code should ideally
>>> go because it looked like most (all?) of your IWC Code is in the
>>> Clients Javascript code.
>>>
>>> So, what I would like to add to Rave is:
>>>
>>> 1. a class that manages the XMPP Server. It would basically make sure
>>> that a pubsub-node is created for every Page and a new JID is created
>>> for every User. I chose to implement this as an IWCService Interface
>>> with a DefaultIWCService alongside the other Service and
>>> DefaultService classes that will handle the XMPP Server but I'm not
>>> sure if there might be a better place for this.
>>>
>>> 2. make rave create a pubsub-node for each new Page and a JID (+
>>> password) for each new user. I'm not sure where and at what time this
>>> should be done as there are many classes that work with Pages and
>>> Users. My best guess would currently be the "DefaultUserService" and
>>> "DefaultPageService" classes. These would in turn use the IWCService
>>> to do their work.
>>>
>>> Any input on this would be appreciated.
>>>
>>> Best regards,
>>>
>>> Andreas
>>>
>>> [0] http://www.role-project.eu/
>>> [1] https://issues.apache.org/jira/browse/RAVE-25
>>> [2]
>>>
>> http://www.slideshare.net/DominikRenzel/role-technologies-a-possible-contribution-to-apache-rave


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