Notes from the Meeting of May 28.

B. Clark noted that the Nucleus toolset does provide an overlaying linker,
so that it is possible to have the software for the device in a separate
module from the system and services.  This will require careful management
if we decide to do it, since the links can only go from the overlay to
the system, and not vice versa; also great care will be needed to make
sure that the overlay is linked with the correct version of the system.

B. Sahr reports that the OS port procurement is proceeding with all
deliberate
speed.  He has separated the port procurement from the tools and simulator
purchases to make sure that long lead item gets underway as soon as
possible.

W. Koski says he is proceeding with all deliberate speed to make the
mezzanine card to interface the on chip MAC to a network PHY chip.

B. Clark made a list of the various communications one expects with the
MIB, or with the Object residing therein.  Reproduced below, with some
afterthoughts added.

What does a MIB say

Monitor point to be logged
Monitor data to verify command
Checker message to the operator
Error message for bad command
Flag "My device makes the data no good."
Here I am; I have just booted
Monitor point to be snooped by screen

What do you say to a MIB

Execute a command to your device
You are "in use"; reject some screen
  commands
At the tone, the time will be ....
Reboot
Write to your flash
Change your logging/verification/chatter
  time intervals
Report your currently active checker messages

Q and A

What is the value of this monitor point?
What are your monitor points?
Do you have Device objects below you in the hierarchy?
What are your commands?

R. Moeser reported on some speed measurements of various communication
protocols.  Fastest was just sending a binary buffer, of course.  This
tends to be about a factor of ten faster than the next faster, which is
Java RMI, which serializes the object, sends it over a socket, and then
reconstructs.  Slowest is SOAP, which involves converting all values to
ascii, encasing them in XML, and sending them serially.  SOAP is inefficient
in both bandwidth (it takes a lot of characters to represent floating point
values) and CPU time (mostly spent in sprintf).

----- End Included Message -----