JNLDM Status Report

Michael Linck, September 2003

Intro

I have been asked to write a pararaph or two about my activities during the few months I've spent with Unidata, but I warn you, I'm wordy. As some of you know, all of my time so far has been devoted to the expansion/rewriting of what has - sort of - become known as the jnldm. That is to say, that I have very little idea how many people actually know about it. I don't exactly go up to people I meet and say, "Hi, I'm the guy that's trying to write the JNDLM." If I do, people usually get that glazed over look in their eyes that suggests they have no clue what's going on anymore.

Anyway, the JNLDM is an NNTP-based version of the LDM, which happens to be written in java - the JNLDM, not the LDM. At current it seems to be efficient enough to at least function as a leaf-node in the network. It may be a little slower on Windows machines, but I have not had the chance to really do any thorough performance testing outside a UNIX environment. Of course, claims were being made at Project Ellis's final presentation that this was already the case, so "what have I been doing for the last four months," you might ask.

I was a part of Project Ellis, which was a group of college seniors, trying to complete their assignment and get a good grade from their professor. They were also a little busy, so a lot of the code they wrote was a little sloppy. There was lots of code so the slop sort of accumulated. I also didn't write even a majority of the code that was produced that year. Victor Przebinda and Doug Hakkarinen were actually the main coders on the team. Doug had been working for Sun for quite a while and Victor...well, we didn't know what was wrong with Victor.

Getting Started

So, when I started working for Anne Wilson, the first thing I had to do was to get to know the code, and know it well. I spent the first few weeks doing just that, and started optimizing the system after a little while. This seemed like a good way to get to see the code from a lot of different angles, with OptimizeIt as my guide to all the things that were basically wrong with it. This initial optimization stage lasted for roughly a six weeks and ended up encompassing some of the modifications which I'm about to talk about.

Completed Work

Detailing

Once I felt comfortable enough with the code, and basically understood how every part of the system interacted with every other part it was time to start making bigger changes. There were classes which could be rewritten, omitted, integrated into other classes, separated from other classes etc...all in the interest of maintainability, legibility and just generally making the program easier to understand for any poor fool who may be stuck with it at some point. There were also some very basic design flaws.

Redesigning

The entire segment which actually performs LDM functions, such as deciding what happens to a given data product had a very counterintuitive interaction protocol, and all of the classes which it contained had GUI components built into them. The functionality of these classes, or any of the classes that constituted the backend, had very little to do with the functionality of the GUI. The GUI was merely a complicated editing tool for a configuration file, afterall, so I decided that the code for the GUI should be separated as much as possible from the code for the backend. As a result I spent about three weeks rewriting that particular piece of the program. When I got done, there was significantly less code than when I'd started, a good sign. At this point it was time to start adding functionality to the program.

Statistics

The JNLDM, ever since it the idea was conceived by Anne Wilson, was supposed to be able to relay statistics to a website, which the user could then look at to see important aspects of their program's performance, and immediately compare their own performance to that of any other computer in the network. The JNLDM, when Project Ellis got finished with it, had a very simple statistics module which kept track of byteCounts, # of messages received, and some latency statistics, but which had no way to relay any of that information to the website. That functionality had to be added, and because the initial module was not built with a relay-capable architecture in mind it had to be rewritten as well. This part of my project involved writing an entirely new data Relaying mechanism and adapting the rest of the program to use it, as well as writing several classes which would manage the statistics internally. The statistics functionality ended up having to be integrated into the LDM part of the program because the user needed to be able to configure parts of it. When it was finally done, if it is done, about two months had been spent on Statistics related tasks. Then it was time to work on the new GUI.

Currently Doing...

The old interface had been completely removed from the code at this point, to make the backend easier to work on. After writing aforementioned LDM-related chunks of the program the the program was no longer compatible with its old GUI anyway. Besides, those of you who saw the demonstration my classmates and I put on last May know that the old GUI was difficult to use, counter-intuitive, and, let's face it, ugly. I've been working on the GUI for about two weeks, and, though not quite finished, what I have accomplished looks a lot better, to me anyway, than what was there before. After I get the initial GUI-architecture finished I plan to have to make at least one more pass over it to add details, like hotkeys, user mnemonics, and warning dialog panels. For the moment I'm just taking notes on what will remain to be done and trying to get a complete framework set up which will, hopefully, allow me to make the required improvements relatively quickly on a second pass.