rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Franklin <m.ben.frank...@gmail.com>
Subject Re: ROLE IWC for Rave
Date Tue, 15 Jan 2013 01:49:17 GMT
On Mon, Jan 14, 2013 at 2:55 PM, Andreas Guth
<andreas.guth@rwth-aachen.de> wrote:
> 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.

I would recommend that we make this configurable through the portal
preferences admin section so that it can be disabled globally and
configured by an administrator.

>>> 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

View raw message