JNLDM Status Report
Michael Linck, September 2003
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.
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.
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.
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
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.
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.