wulfstat is a program designed to run on a tty interface and provide
detailed monitoring information on a collection of networked cluster
nodes or workstations.  It gathers the information from xmlsysd, a daemon
that runs on the nodes or workstations, collects information from /proc
files or systems calls, and returns it in an xml-based format via a tcp
socket connection.

5/17/02 -- added support for <hostrange> and <iprange> tags, fixed various
bugs.  Checked in tagged as llist_2.  And maybe as llist_3 -- since I've
also broken out routines for parsing the <host>, <hostrange> and <iprange>
tags AND for adding them (separately) out of linked lists that can be
manipulated for purposes of building a wulfhosts file to be saved.

5/20/02 -- I went ahead and incremented minor revision by .1.  At this
particular instant, the program "works" including all the aforementioned
tags, and I can even verify that I'm reading in the tag contents.
HOWEVER, I haven't yet gotten any code in fill_values to work to parse
out the returns for each monitored PID, and suspect that a merry time
will be had working all this out.  The primary issue here is that we
have to fill the linked list of running PIDS EACH PASS through, either
updating an existing struct or deleting a dead struct and starting a new
one.  I don't know whether this will be efficient enough -- free/malloc
can be fairly costly in time.  We'll see.  With a fairly slowly varying
list of entities, it may be fast enough.

I must confess: I maybe possibly shoulda written the entire program to
get values directly from the xml structure and never moved them into an
intermediate position.  If I had done this, I wouldn't have to worry at
ALL about allocating intermediate storage, only about efficiently
extracting values from the linked list of xml structs (which are
basically linked lists).  The only exceptions probably should have been
things in <stat> and <net>, where there are derived rates.

Is it worth a complete 0.3.0 rewrite to implement this?  We'll see.

Much time passes... up to 10/8/02.

OK, we've learned several useful tricks in the meantime.  One of them is
pthreads, which is a lightweight shared-memory thread library that is
vastly better than fork/exec in any flavor as far as ease of use is
concerned.  The other is how to actually use the windowing features in
ncurses, which we alas failed to do before.

SO we're going to try a short-term rewrite of the tty interface with the
following design goals:

  a) A separate window for the various critical elements of the program,
in particular, the header line(s), the menu lines, the bottom line and
the DEBUG WINDOW! should all be in windows of their own.  So should the
actual output!  We should also use "window borders" (see man box_set)
rather than doing this the hard way to separate windows.
  b) Implement scrolling rather than F/B keys to get up and down in a
host list.  ncurses supports the scrolling of a virtual window -- so
should we.
  c) Simplify the debug window and debugging output.  Basically, as long
as the debug window is scrollable, it can just be a dumb tty with no
line control.  Also, keep in mind resize_term and wresize -- it is
perfectly reasonable to require a MINIMUM of (say) 20 lines for regular
operation, 30 lines for debugging operation, and exactly 80 columns for
the xterm display.
  d) Life would be simpler yet if I think ahead to how wulfstat will
need to morph to become gwulfstat.