2013/5/24 Matt Franklin <[email protected]> > 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. > > done: https://reviews.apache.org/r/11421/
FYI this bug http://code.google.com/p/reviewboard/issues/detail?id=2359 Seems to be still in the version of review board you are using. Took me an hour to submit the patch... > > > > > 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 > > >
