CoqDevel

the stuff Coquelicot does when it thinks it is at work

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.

0 Comments:

Post a Comment

<< Home