Hi, I would like to share the finished implementation for remote IWC with you. The patch is available at http://dbis.rwth-aachen.de/gadgets/rave/remote-iwc.patch and applies to the latest SVN trunk. With this patch widgets are able to interact with widgets on shared Pages that are viewed by multiple people at once.
There is a short video showing the interaction of widgets between to browsers available at http://youtu.be/iw6RSI1T7nM (watch with annotations on) For anyone who wants to try this out, there is also a manual describing the necessary steps to get this running and what you can do with it. That includes the setup of a XMPP server that is necessary for this implementation as well as the configuration of the Rave server and creation of widgets that use remote IWC. It is available at http://dbis.rwth-aachen.de/gadgets/rave/iwc.manual.pdf This implementation of remote IWC is build upon the OpenAjax IWC that is used in the OpenAjax Subscriber and Publisher widgets that are included in the Apache Rave widget store. Because of that widgets that already use IWC will require only minimal to no changes to work with remote IWC. (None in the case of the two mentioned widgets). As already mentioned remote IWC is realized with the help of XMPP. In the browser a special branch of StropheJS is used that supports BOSH and Websocket connections. To publish and deliver IWC messages between clients the pubsub extension for XMPP is used. The code for this has been contributed from the ROLE Project[1] and I'm hoping that this patch can be merged into the Apache Rave project, so it would be great if some of you could test this patch and tell me what you think of it. Comments are very welcome. [1]: http://role-project.eu 2013/1/22 Matt Franklin <[email protected]>: > On Tue, Jan 22, 2013 at 12:47 AM, Andreas Guth > <[email protected]> wrote: >> Hi, >> >> I'm currently running into some problems while integrating the ROLE >> IWC and I hope that someone can answer a few questions about the Rave >> code. I'm guessing most of my problems are due to the fact that I >> never developed with the Spring framework before. >> >> 1. >> I tried to alter the User model to include a second password used only >> for IWC. To create this I also use the password hashing function that >> is used for the normal password. After I added this all the tests for >> User creation stated failing because I was running the password >> hashing function twice. I'm think I can make the tests pass again by >> altering all User creation tests but I guess my question is if there >> is a better way to fix this. > > Rave uses EasyMock[1] to create mock dependencies. You only need to > add another expectation to the mock so that it knows that it will be > called more than once. > >> >> 2. >> I see that Rave is using Spring to load Properties from a .Properties >> file for configuration. My plan is to include the XMPP options in the >> same way as tho mongodb options in the Properties file. I couldn't >> find the code that actually loads and uses these values in the Java >> code though. I'm guessing I just overlooked it, so if someone could >> tell me which file/function/line I have to look up to see how you do >> this, that would be great. > > The Mongo bean creation is managed by a Spring XML context, which is > why you don't see it in Java. MongoDB's configuration is currently > required at startup time and must stay in properties (at least without > rework of how we load beans). For the XMPP server though, you might > want to consider letting it be database driven via the > PortalPreferences in the admin section. In general, I think we need > to put more of the configuration into the portal properties and less > in properties files. This gives us the greatest flexibility in > deployment. And for those who would like to keep all configuration in > properties files, all they have to do is implement the > PortalPreferences repository to load from properties. > >> >> 2. >> In ROLE the XMPP credentials are provided to the client via a call to >> the opensocial API and the XMPP host/port via a static JavaScript >> file. Because Rave does not seem to have the same API in place and >> because there are many possible ways to send data to the user, my >> question here is what would be the most straightforward way to get >> this data from the backend to the user in the Rave framework. Again, a >> pointer to some code that does something similar would be great. > > You might need to create a new API endpoint in Rave itself. On the > shindig side, you should be able to use a feature with static js or > make a call to the Rave endpoint. > >> >> Thanks, >> Andreas > > [1]:http://www.easymock.org/EasyMock2_2_Documentation.html
