Updated Coral Wish List ....

John Shott shott at snf.stanford.edu
Tue Apr 2 17:36:05 PST 2002


Bill and Mike:

Following is the wish list that I generated a month or so ago ... I've now
updated this to reflect recent progress and added a few things that, I
believe, represents a preliminary set of "new challenges" that may have
emerged at Java One and elsewhere.  I've also tried to make a preliminary
estimate of "priority" and "effort required".

This is still a working list and doesn't really include proper prioritization
...

Hardware Stuff:

1. Install Solaris machines, including RAID disks, SunRay failover, etc.
(Well, this includes software stuff as well ... Oracle 8.1.7, etc.) ... Mike's
made recent good progress in this area.  At some point, before we can test
failover, I think that we probably need to upgrade the SunRay server software
on Sunray from version 1.1 to 1.3.

2. Get faster Linux box for development effort (probably in one of the black
rackmount boxes). ... I think that we are done here.

3. Improve firewall machines ... Low priority.  

Overall Software Stuff:

1. Deploy Coral at Penn State ... Our highest priority!!! I have to be able to
tell NSF that it is running at Penn State on May 6.

2. Deploy Coral at MIT  ... While they aren't yet in production, it appears
that Ike has been making excellent progress and at least has a development
version of coral running against Oracle 8.1.7 and has functional servers,
clients, and remote clients.  Major progress!!!

3. Deploy Coral at UCB .... Hmmm.  Apparently no good news here ...

4. Update firewall software including mechanism to allow rosen to
communicate through the firewall with remote clients.  ... Probably pretty low
priority as few servers are likely to run from behind firwalls.  We probably
have multiple options including "SOAPing" the remote client, simply buying
something that allows CORBA through a firewall, etc.

5. Update daemon/driver to run under newer versions of RedHat and consider
updating walker to that version.  ... Nothing done here.  Low priority until
we want to look at something like facility monitoring or sensor reading.

Supporting software Stuff:

1. Finish update of adjustments in monthly accounting scripts. ... Bill is
working on this as we speak, including improved support of multiple "types" of
projects. (Actually, the adjustment part is fine ... it is updating them for
Postgres and incorporating different rates for different "type" of project
that is the main activity.

2. Finish sprucing up Makefiles including rsync stuff. ... While it's not
perfect, I think that we've made good progress here and have improved this
significantly.

3. Update newuser, and set_password for rsync. ... Nothing done.  Improvements
here would probably be useful at MIT and Penn State, too.  Also, once these
scripts are spruced up, we should insert them into the resource client so that
"Add member" not only adds them to the database, but sets up an account for
them as well.

4. Study and adopt "report generation" strategy.  Ideally an affordable,
commecial means of generating Excel files from our database with "pre-canned"
queries.  ... No real progress here.

Predominantly Server Side Stuff:

1. "Configuration manager" capabilities with more parameters coming from the
DB (where possible). ... Bill, am I remembering correctly that this is one of
the places where JDOM and XML documents look to be of use?

2. Admin manager update to start/stop other servers. ... This would be nice
(particularly as it would allow servers to be started in "as soon as the
previous server was up" timing instead of the fixed timing that we use in the
current servers script.   However, I'm not sure that this is, by itself, a
terribly high priority.  However, it is likely that this would be done when
improved monitoring and logging are done.

3. Admin manager monitoring of performance statistics. ... I think that this
is also an area for incorporation of the 1.4 logging mechanism and allows us
to remotely monitor not only our servers and clients ... but those at other
sites as well.  This could be one of the most important areas that would allow
us to support other sites running Coral.

4. Migrate from ABA JCE stuff to Bouncy Castle.  (I'm worried that a soon as
JDK 1.4 if officially released that we will begin to see people running 1.4 on
their Remote Coral machines.  As soon as they do, I fear that Remote Coral
will break because it comes with the Sun JCE stuff pre-installed.  I think
that the solution may be to convert to BouncyCastle.  If someone is running
1.4 on their remote machine, then they only need to download the BC provider. 
If, however, are running on a 1.3+ machine, then they would need to download
the signed BC JCE implementnation plus the BC provider ... at least I think
that is what is required).  Note: this assumes that BC encryption/decryption
can decipher the existing ABA encryption ... I don't know that is true.

Predominantly Client Side Stuff:

1. Add "Replace Project for all Members" (that is ... for every member that
has an active ability to charge to Project A, terminate that works_on entry
and add a new ability to charge to Project B (with appropriate actions in
various activity/adjustment tables ...)  (I've actually notices a few funny
things with the resource client ... for example, after selecting a new member
and then doing an "Edit member", I got the info for the previously selected
member instead of the currently selected one ... I don't know how reproducible
this is, but ...)

2. Come up with a way of displaying all reservations for a given person on a
signle GUI panel. ... Probably lots of people would like this.

3. On history panel, add "red" and "yellow" shading for problem/shutdown
periods.  ... Not a terribly high priority, but it should be comparatively
easy to do.


4. Resource client needs some "repaint cleanup". For example, pulldown menus
often continue to display (at least partially) after they are no longer in
use.

5. Add "labwho" capability that shows who is in the lab (based on info in
current_lab).

Both Client/Server Side:

1. Inventory Client/Server  ... High priority.

2. Recipe Client/Server

3. Think about and implement "more than one lab" capability.  ... it's not
completely clear taht this is needed.

4. Look at using "Walker boxes" for door interlock hardware including explicit
addition of "Enter Lab" and "Exit Lab" pulldown menu items (note: these Enter
Lab and Exit Lab menu items are actually different than the enterLab and
related method in the Admin Manager.  (Actually, it would nice to be able to
add support for multiple doors ... including the main lab door, add hardware
to control the "blue coat" maintenance entrance, room 151, etc.

5. Update/adoption of Berkeley "Faults" system.

6. Facilities monitoring client/server/hardware ... there are lots of
interesting things that could be done here and many of them would be used by
lots of different labs.

Let me know if you have additions to this list or don't understand what I mean
by some of these items.

Actually, I think that there a few other things that might be useful to add
based on some of the things that were learned or seen at Java One:

1. Consider a PDA-Coral .... this could be fun, have lots of "Gee Whiz"
appeal, and even be useful.

2. Explore an appropriate development environment ...Sun Forte and Eclipse
(which, I gather, is the public domain version of VisualAge for Java).  Ike
seems to like Forte ... and likes VA even better so it would appear that
either Forte and/or Eclipse may be in our future ...

3. Ultimately migrate to an ant build process ... probably makes sense in the
long run and would be smart for a brand new project but is a lower priority
since we have so much invested in the Makefiles and they appear to work
reasonably well.

4. Equipment monitoring, data extraction, and recipe downloading ... there
appear to be serveral Java SECS implementations including J-SECS from
ErgoTech.  This might be a good area of some initial exploration of xml
documents for specifying recipes and/or measurement and using J-SECS (or
equivalent) for the low level communication of this information to/from
equipment.


I've probably forgotten more things ... every time I think about this, I can
come up with something that we've forgotten.

Talk to you later,

John



More information about the coral mailing list