Updates wish list ...
shott at snf.stanford.edu
Mon Apr 8 10:22:24 PDT 2002
Bill and Mike:
Following is my updated Coral wish list including a very preliminary attempt
at prioritizing things. If this looks OK (or, once it looks OK ...) I'll plan
to send this to MIT. Please let me know if there are things that I've
forgotten, overstated, understated, etc ...
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. ... High priority.
2. Acquire technology so that remote clients can reach our servers through a
firewall so that we can put our servers fully behind a firewall once again.
Candidates includue the Domain Boundary Controller from www.xtradyne.com.
Other options may include CORBA-aware firewalls. Alternatively, we could
conisder adapting the remote client to use SOAP instead of CORBA
communications. ... Medium priority. (Note: I put this in the Stanford-only
list because it is not yet clear that there are other sites that will be
running their database/system from behind a firewall ... if there are, then
this becomes a broader issue).
3. Improve firewall machines ... Low priority (but probably should be done at
the same time that we handle #2 above).
I'll let Ike and Tom fill this in ....
Overall Coral Matters:
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. This requires 3 things:
a. We need equipment/accounting initial table population from Penn State
b. I need to be able to convert their tab-separated files into appropriate
Postgres "Insert" statements.
c. Bill needs to finish adding different charge rates for different "types"
users (local, industrial, etc.) and get the accounting stored procedures
working with them. (This, of course, implies that they
will work with Postres as well.)
2. Deploy Coral at MIT ... Major progress!!! Ike and Tom have a development
version working with Oracle 8.1.7. Hooray!!! Ike and Tom: we need to know
what the hurdles are between now and getting things in production ...
3. Deploy Coral at UCB .... Hmmm. Apparently no good news here ...
4. Explore an appropriate development environment ...Sun Forte and Eclipse
(which, I gather, is the public domain version of VisualAge for Java). I also
gather that VisualAge had had its last release and that future enhancements
will be applied to Eclipse. I think that Ike has the most experience with
these systems ... Ike and Mike should work together to see what fits best in
5. Spruce up the resource client/server so that "add member" actually adds the
new member to the database (which it already does) AND gives them a system
account, sets up mail forwarding appropriately, etc. These are currently done
by separate scripts that are not run from the resource client/server. We
should factor this in with the JNI auth things that MIT is interested in
6. Study and adopt "report generation" strategy. Ideally an affordable,
commecial means of generating Excel files from our database with "pre-canned"
queries. ... Commercial candidates include e.Spreadsheet (formerly Formula
One from Tidestone) from Actuate or products from www.jinfonet.com and
www.extentech.com (ExtenXLS), and probably others. e.Spreadsheet is nice, but
pricey! No real progress here.
7. 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.
8. Consider a PDA-Coral client running on top of J2ME .... this could be fun,
have lots of "Gee Whiz" appeal, and could be increasingly useful. But it is
probably a lot of work to figure out how to make some of the essential clients
9. 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. Also, the "non-Java" stuff that we need to support including
SQL stuff, shell scripts, JNI things, etc., may offer a coplication in
adopting the ant build route.
10. 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. Probably a fairly low priority until there is a louder cry for
actual communication with hardware (other than enable/disable stuff, of
course) ... and a lot of work.
Predominantly Server Side Stuff:
1. Enahnced "configuration manager" capabilities with more parameters coming
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 better support other sites running Coral. Because of its felxibility,
adopting the new 1.4 logging mechanisms as a replacement to the
System.out.println and System.err.println statements is probably a good thing
to begin to work into the overall system. If we gain a little experience,
this may be able to be added incrementally one client or server at a time.
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 noticed 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 ...) Also, many of the popup windows come up with a size that
shows most of the fill-in fields as being zero-width. I think that this is
because we are specifying the popup window size at a high level ... rather
than letting it be the size that it prefers to be.
2. Come up with a way of displaying all reservations for a given person on a
single 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
5. Add "labwho" capability that shows who is in the lab (based on info in
6. Rework the maintenance client to be more user friendly. At a minimum, it
needs to be able to display the entire text of problem/shutdown messages.
Both Client/Server Side:
1. Inventory Client/Server ... High priority.
2. Recipe Client/Server ... MIT is driving the bus here, but I think that at
least rudimentary capability in this regard is a high priority.
3. Think about and implement "more than one lab" capability. ... it's not
completely clear that 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. 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. For starters, this would be using the Walker ISA card
to interrogate 4-20 mA sensors to read pressures, temperatures, etc.
6. Update/adoption of Berkeley "Faults" system. This will probably wait for
UCB to be fully on board as they will be the likely driving force here.
Let me know if you have additions to this list or don't understand what I mean
by some of these items.
It's clear that there are a long list of enhancements and improvements that
can be added to Coral.
As usual, your comments, suggestions, and corrections are welcome.
More information about the coral