On Tue, May 21, 2013 at 11:15 PM, Andreas Guth <[email protected]>wrote:
> 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. > Very cool! Would it be possible for you to submit this through review board, so we can more easily review it? http://reviews.apache.org. > > 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 >
