Last week Friday Florida Tech accepted my Thesis. You can currently read all 101 gory pages here. I’m pretty over the moon with being done with my degree and am taking a week or so to relax. At least one of the professors that reviewed the work was excited about its applications and wanted to know when it could be used in a real life classes. There is also the possibility that the crypto & security work may be taken up by a senior projects group.

Right now I need to do several things before development can continue. On the organisational side I want to change 3 things:

• Get the source code hosted in a Subversion (SVN) repository. SVN supports renames correctly for directories which is critical when you go to rename packages in Java, something I have no fear or compulsions about doing. We may eventually host downloads from Sourceforge but I have no interest in using CVS as the repository.
• Get a MediaWiki up and running to host all development discussion, like how they do for Firefox.
• Set up bug tracking with Bugzilla.
• Choose a Licence for the code and add it to all source files.

For an open source project those are the best in class tools. The SVN may be problematic because it requires special installation & configuration. The MediaWiki and Bugzilla should run from my current web host.

The other stuff is more about what direction the project should take. Particularly with regards to networking technology and JXTA. I got a profiler out and I am not too happy with what I see. Even small JXTA apps like MyJxta have a 50MB footprint (comparable to Limewire or Azureus) and they randomly chew up the CPU even when idle. JXTA also has issues with the speed of its DHT searches, aka the Discovery Service, which made it useless for presence support. It also takes a long time for each node to startup  and join groups. Interestingly JXTA is not I/O bound as one might expect, being a networking technology and all, actually its XML processing boutd, spending about 67% of its time munging XML documents. You get lots of cool stuff like NAT traversal ‘for free’ with JXTA, the question for me it just how free is it for my particular application?

Sometimes I surprise even myself! And it only took 3 hours.

I took a look at JNLP. I have made some choices about loading resources that wont allow mindshare to work as a JNLP app until they are fixed. Basically this was a testing convenience. I can set the working directory on each instance to be different and everything will be stored in that directory. This is great when you are running two or three peers on the same machine as a test. JNLP puts things in strange places and renames resources. The ‘right’ thing to do is to store everything in the users home directory. This would only allow one peer per user to run. The right solution it to allow the app to take command line parameters to put it into testing mode. This would probably take a day or more to fix so I wont get JNLP working any time soon.

I switched to Log4J from Java’s built in logging API. I am very happy with the switch but the log window in the app has broken. What I really want is a coloured log output in the log window. Something like this:

 This would make debugging at any location just a bit easier. The output would be in HTML of course and you could save the logs. Trouble is there appears to be no off the shelf solution for hooking up a log appender to a JTextPane. i wrote the Layout in about 10 minutes though. I may take another crack at this tonight because I really like the idea of being able to read the logs anywhere.

Not a very productive day but its the first real work i have done in about a week.

New:

• Work on BEEP connections between peers.
• Peers decide who is the ‘client’ and the ‘server’ by comparing the URI’s of their respective JXTA PeerID’s. The lesser PeerID is the client and thus responsible for making the connection.

Refactoring:

• All the old logging code is now replaced with Log4J.

Bugs:

• Fixed a subtle bug in Presence that happened when peers went offline and came back rapidly. The per record would be replaced and a timer task would remove a different but ‘equal()’ record.
• Fixed a synchronization bug in Presence shutdown where concurrent modification could occur in the peer list.
• Found a subtle bug in the buddy list display. If the list is interacted before all peers appear online it will not display new peers. Most curious.
• Also the buddy list is not being saved as it was before. This is actually a cool feature at this phase of testing so it may be made optional with the default being true.