the stuff Coquelicot does when it thinks it is at work

Wednesday, September 14, 2005

configuring local Jabber server

I've spent half of the day trying to configure fljud Jabber component on out internal Jabber server (fljud is implementation of Jabber User Directory that gets the data from LDAP, which we are now using). Old version was working properly, unfortunately, it does not support discovery protocol. I've grabbed new version (fljud-0.5 alpha) and it started to crash. So, I decided to switch the athentication method from LDAP to MySQL (data storage is running MySQL right now). There is another JUD implementation that is based on MySQL called 'users-agent' and it looks that it is a very simple JUD - keeps one table in database and writes/reads user's data when user is created/queried for. This means that all the users need to be re-created - and I'm even willing to do that, but right now I'm getting 'Internal server error' when I try to add new user by using JBother. Tomorrow I may try to use different client, just to see if maybe this is client's fault.

Next step would be to re-configure bandersnatch to use the local database (right now is using remote database). This would be better, considering that other machine is located o very busy network. After that I will set up the backup subsystem to get all the data backed up, "in case of".

Tuesday, September 13, 2005

more improvements on CGMTI Generator

Splitting the MTIs into more than one UDP packet is still the main objective, but before that some changes needed to be done to the existing code. First of all, right now the generator is using the singleton class to represent itself (thanks to Marco and Synic for the sample code!).

I've also managed to get the 'right-mouse-click' editing working (something that I kind of dropped in previous release), so now user can edit all segments from context menu bu right clicking on segments, but still some more work needs to be done to get the details working - like synchronisation with Message menu, for example. As soon as I have everything working with one GMTI package, I will be able to add a list of packets in place of single one. From there, we will only need to have one method for splitting the packages into separate UDP packets (this may be little tricky when we consider the possibility of later edition of packages - so, let's say, we have 2 packages, split by the magic method and then we modify the first one by adding or removing target reports. Should the package be re-packaged? if so, should the index numbers of TRs be changed as well? etc etc).

I've also spent some time talking with Simon Z about problems with compilation of SSR plugin. Looks like 'build.xml' file requires that end uses has all packages (Smack, our Smack extensions, our utils etc) available in source form. I don't know if this is good or not, theoretically end-user shouldn't have to do too much to get things compiled. I need to think about that.

Monday, September 12, 2005

CGMTI Generator: splitting MTI packets over multiple UDP packets

Trond & Joe decided that it would be nice to have the possibility to generate larger MTI packets than UDP's packet length (1472 bytes). This would require splitting target reports over multiple GMTI packets. The overall procedure seems to be pretty simple: user would state in GUI how many packets would he like to have in one packet, the value would be then checked if it fits and the following thing would happen: new GMTI packet would be created and the those target reports that would not fit in first packet, would be put there, according to the rules stated in GMTI implementation document.

This seems very easy but it requires substantial changes in GMTI Generator's code: right now it can only deal with one GMTI packet. I've already managed to change the way the popup menu is called - after discovering that Marco's code makes it also possible to get the `regular' GMTI segment objects out of XML (right now the JTree is build based on XML generated from regular objects, it is much easier to display the structure). I also need to implement `singleton' class for GMTIGenerator class, as it has only one instance and it would be much easier to use it from within other classes, including abovementioned popup menu.

Thursday, September 08, 2005

back to JBother's file transfer

Now when SSR Plugin is released, I have some more time to look into file transfer. Arnold R (and other people as well) reported that file transfer is simply not working for them. The thing is that the version on the portal, due to the very peculiar "bug" in build.xml file (more below) was not providing file transfer capability at all.

The situation was as follows: when an XMPP packed is received by Smack, it is parsed to 'provider', class that reads the XML and creates an object corresponding to the XML. The decision which object is which is based on type of the packet: ( or ), element's name ( or in case of file transfer) and the name space of the top element ("jabber:x:data" for data forms). File '$JBOTHER/src/smack.providers' contains XML-formatted list of those criteria, together with class name of provider object that will receive the XML to do the parsing and create the Smack object.

The problem with JBother was that 'smack.providers' existes in more than one place, namely in Smack's 'smackx.jar' archive, normally located in '$JBOTHER/lib/'. Then Ant's build.xml script, before packaging compiled classes to their final 'JBother.jar' archive, was supposed to unjar contents of lib/ directory, copy JBother's 'smack.providers' file and package the whole build/ directory to JBother.jar (executable).

Unfortunately, copying of JBother's 'smack.providers' was not overwriting one from 'smackx.jar', so no definitions for our classes for handling file transfer (and jabber user directory BTW) were not there. That's why I was getting IQ errors 501 "feature-not-implemented".

Now it would be nice to extend the existing (very crude, I know) file transfer to make it look like Psi. Some more stuff like bytes/sec and ETA would be also nice to have. JBother community also wanted to implement NAT code, I think it would be nice to get this thing working.

SSRPlugin 0.2 - minor changes

After Trond's e-mail I've changed slightly the behaviour of SSRPlugin. When Requestor cancels its request, he is not supposed to provide the reason (appropriate entry in SSR schema looks like that: <xsd:element name="Cancel">, which implies that <Cancel/> element should be empty). I still keep a pane for `Cancellation reasons' when Acknowledging station denies the request - it will display the message informing the Requestor that his request was denied.

Tuesday, September 06, 2005

SSRPlugin 0.1, Smack Extensions 0.3 and NC3AUtils

Lots of updates: version 0.1 of SSRPlugin, corrected version 0.3 of Smack extensions (thanks Wouter K from TNO for finding the bug!) and updated version of in-house nc3aUtils package. All available on the portal.

Wouter K spotted the bug (in fact, the version on the portal was too old to get it to compile the SALT plugin with it) because he is working on different type of SALT plugin, that would pass the SALT data to their own application. It would be interesting to see how it works for them, maybe e could merge the two?

Friday, September 02, 2005

finishing beta release of SSR plugin

Today lots of new stuff added to SSR plugin: default template loads when user is composing Initiate request message (this should save some [boring] typing); another template is used for acknowledgements (platform ID including nationality and platform name). Also, buttons are changes accordingly to current context. Still there's need for some extra notification area (like status bar?), as I have problem with JOptionPane (for example, when requestor's request gets finally accepted without more modifications, I want a dialog box pop up before displaying accepted request - and it does but it blocks the rest of operations).

I'm pretty sure that the plugin is almost ready for release early next week.

BTW: I managed to fix the bug in nc3aUtils package - problems with conversion deg/min/sec to double (due to roundings, I was never able to get it right). SALT plugin, CGMTI Generator and other packages will be recompiled and uploaded on the portal. Dialog for entering coordinates uses now JSpinners in place of JTextField - it makes it easier to enter values with the mouse and is the syntax checking is much easier (by using SpinnerModels).

Now, weekend time... :-)