rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Guth <andreas.g...@rwth-aachen.de>
Subject Re: ROLE IWC for Rave
Date Mon, 14 Jan 2013 19:55:05 GMT
2013/1/14 Chris Geer <chris@cxtsoftware.com>:
> On Sun, Jan 13, 2013 at 9: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.
>>
>
> Will there be a way to enable this on a page by page basis? For example,
> only be done on pages that include a widget that needs this pubsub?

Currently it would be enabled on all Pages. I'm not really sure how
and why you would want to disable it for specific Pages though. The
only difference in the backend would be one entry in the XMPP Servers
pubsub-nodes, so I don't see the benefit in checking specific widgets
in a Page. It is currently not planned but what could be done on the
client-side is to only establish an XMPP connection if one widget
first tries to use IWC.

>
>>
>> 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.
>>
>
> Is this intended to replace the current pubsub (between widgets) or work
> with the current pubsub to extend it over multiple containers?

It is intended to extend the current pubsub. When a message is sent to
the local pubsub it would just additionally be published over XMPP to
other Users that are using the same Page and also be distributed there
through the current pubsub implementation.

>
>>
>> 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
View raw message