On Mon, Jan 14, 2013 at 2:55 PM, Andreas Guth <[email protected]> wrote: > 2013/1/14 Chris Geer <[email protected]>: >> On Sun, Jan 13, 2013 at 9:34 PM, Andreas Guth >> <[email protected]>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 >>>
