On Fri, May 24, 2013 at 10:01 PM, Andreas Guth <[email protected]>wrote:
> 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/ > Thanks. We will take a look and provide any specific feedback there. > > 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... > I will let the infrastructure group know. > > >> >> > >> > 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 >> > >> > >
