Posts Tagged ‘XMPP’


05.03.2009

Xmpp connection from within Firefox extensions

posted by Karsten

in RedGloo

In the MeAggregator project I need an Xmpp chat connection from plugins to the central FFS (don't mind if you don't know what an FFS is…) And I have tried using several Javascript libraries (Xmpp4js, JSJaC and Strophe) from within XUL, all of which ended up in hilarious fun and no resulting xmpp connections to the openfire server I'm running.

I've now found that I probably should  have used the Firefox add-on search instead of google to find these libraries, as this morning I found Xmpp4moz which is a library dedicated for xmpp connections from within Mozilla extensions (also other than firefox extensions), so I now have a connection through to the openfire server and the real deveolpment can commence…

Share
14.12.2008

MeAggregator server problems

posted by Karsten

in RedGloo

I'm working on a MeAggregator Server, which has been causing me great problems. The biggest problems have been with getting the roster functionality of xmpp4r to work under rails.

The need for this is to validate and display the actual status of the FFS. This is quite important is this will allow code to start and stop the services of the MeAggregator.

Unfortunately this hasn't been easy. First off I started developing on a Windows box at work. I coded in the roster in each function call. This didn't work as the xmpp4r library only keeps a running status of registered users, thus if the roster was created for each call, the roster would be empty each time used, this resulted in the code showing an offline FFS even though it was online.

This lead me to think that I should create a service running along side rails handling the xmpp connection. I found the rails plugin backgrounDRb which should do exactly this. I installed it, and discovered after a while, that for the same reasons that a abadoned creating a bespoke solution this didn't work! BackgrounDRb apparently doesn't work on Windows machines.

Luckily I'm not tied in to any computer systems (as long as I don't have to use Mac which I would regard a degrading OS for a developer 😀 – not really…) so I decided to set up a development environment on my ubuntu laptop.

This didn't take long. But this was the only thing that didn't take time. I couldn't get backgrounDRb to work on my machine. Nothing worked. I kept getting strange internal exception from backgrounDRb. I found the http://mayurjain.wordpress.com/2008/08/08/no-such-file-to-load-log_wor which claimed that the solution would be to use version 0.1.5 of packet instead of later versions. This was odd, as the documentation claimed that v 0.1.7 or later was neccesary for backgrounDRb to run. And obviously this didn't work… Although the background server did start, which was more than before, it simply didn't work when starting p the actual service.

So I started digging into the mailing list of backgrounDRb, and there I found a poor soul, which had similar problmes on a Mac. The suggestion there was that parts of packet seemed to be outside the path, and thus didn't work.

Now I would have hoped that a gem like packet once installed, and a plugin like background using it, would be able to use it without the need of it to be on the path! But todays work has shown that this simply isn't an assumption which can be made!!?? Because when I did a PATH=$PATH:/var/lib/gems/1.8/gems/packet-0.1.14/bin/ in my terminal where running backgrounDRb it worked!!

I am obviously happy it works, although if this issue had not been the re, I would have had this result probably 4-5 days ago, leaving me with these days to do something productive, rather than debugging like this!

Share
04.11.2008

Smack Library Bug

posted by Karsten

in RedGloo

For the better part of 1.5 days I’ve been bug hunting a problem in the MeAggregator code base. The problem arised when accessing a Smack library bespoke client using the Ruby xmpp4r library utilising the the Smack ChatManager (via threadid feature of Xmpp). Every so often the Smack client would seem forgetfull and forget about the thread and create a new one, even though the thread clearly was in use.

I tried everything debugging-wise, believe me, and was starting to give up. But I can now, gladly, declare that I found the bug. 8)

The Smack library store all the treads in a ReferenceMap using new ReferenceMap<String, Chat>(ReferenceMap.HARD, ReferenceMap.WEAK);

Unfortunately this allows the garbage collector of Java to remove the thread if it can’t find any references to the thread string in the memory. Obviously as all other references to the string isin Ruby these will be thrown out.

I’ve now added a simple hashmap to the code which stores the string / chat combination on the java side, and it works!!

I can see why Smack would like to free the memory, but I really believe this behaviour ought to be documented in the javadocs of Smack, so that the code can make provisions for it.

I probably should let them know…

Share
Tags: , ,