| 1 |
Minutes of meeting 29/01/2001 @ 2pm |
| 2 |
Location: UKC Computer Science Meeting Room |
| 3 |
|
| 4 |
Present: ab11, ajm4, pjm2, tdb1 |
| 5 |
Absent: None |
| 6 |
|
| 7 |
Paul informed the group about the host he had written in |
| 8 |
Perl during the week. It has most of the required features |
| 9 |
of a "basic" level host, and is more stable (due to regular |
| 10 |
expressions) than the Java host. Tim reported that the host |
| 11 |
(named ihost) was running fine on all the rocks, and had |
| 12 |
been for over 12 hours. |
| 13 |
|
| 14 |
Tim reminded the group that another stab at a "24 hour" run |
| 15 |
was in progress, which had gone over the 10 hours of the |
| 16 |
first attempt. This was put down to the quota increase on |
| 17 |
raptor for mySQL. |
| 18 |
|
| 19 |
Paul reminded the group of the changes to the database. Over |
| 20 |
the week he and Tim had discussed ways of improving database |
| 21 |
access, as 2 million rows for 10 hours was ridiculous. It |
| 22 |
was decided that a "flat" table with the XML string stored |
| 23 |
in a complete state would be best (with a few key fields |
| 24 |
extracted). Not only should this reduce the number of rows, |
| 25 |
but it should reduce the disk usage. Paul reported that this |
| 26 |
had already been implemented on the server side, and data |
| 27 |
was being added using this method. |
| 28 |
|
| 29 |
AJ told the group about the progress with his client. |
| 30 |
Although there were only a few "cosmetic" changes, a lot of |
| 31 |
work had been done with the "behind the scenes" stuff to |
| 32 |
make it better implement the server protocol, and to make it |
| 33 |
more Swing thread safe. |
| 34 |
|
| 35 |
AJ then informed the group of his plans to improve the |
| 36 |
configuration side of the client, to make it fully implement |
| 37 |
the server protocol, and to improve the visulisation of |
| 38 |
data. |
| 39 |
|
| 40 |
Paul stated that the DBReporting tools would now need to be |
| 41 |
edited to use the new database format, and that he would |
| 42 |
work on this. He also said he'd get some more done on the |
| 43 |
command line client, although it was becoming tricky to make |
| 44 |
it work under both DOS and Unix. |
| 45 |
|
| 46 |
Ash reported that the host development was going well, and |
| 47 |
all the central structure was in place. The "data grabbing" |
| 48 |
part still needed to be coupled with the Perl script, and |
| 49 |
the networking module had yet to be done. Tim added that he |
| 50 |
had some good stuff on networking, and would dig it out. |
| 51 |
|
| 52 |
Ash also discussed some of the ideas behind alerting which |
| 53 |
both the host and the "local clients" would need to be based |
| 54 |
around. Tolerance levels will be stored in the central |
| 55 |
configuration, allowing them to be retrieved by both the |
| 56 |
host and the client. The host would use an "averaging" |
| 57 |
method to send data over longer periods of time, but based |
| 58 |
on these tolerances could send priority packets when |
| 59 |
something "bad" happened. |
| 60 |
|
| 61 |
Tim was last to chip in and tell the group about progress |
| 62 |
with the server. The client interface was complete for TCP |
| 63 |
clients, such as those AJ and Paul are writing. The rest of |
| 64 |
the server is complete, and bugfixes have been carried out |
| 65 |
throughout the system as they are found. Tim suggested a |
| 66 |
"feature freeze" in the server for a while to allow work to |
| 67 |
continue on the rest of the system, and to provide a more |
| 68 |
stable testing platform for hosts and clients. The group |
| 69 |
agreed this was a code idea. |
| 70 |
|
| 71 |
Tim said work was to continue on "patching and fixing" the |
| 72 |
server, but that he would now focus on setting up the |
| 73 |
architecture of the new "local clients". These would use a |
| 74 |
CORBA setup to connect into the Client Interface part of the |
| 75 |
server. Further details to follow when design has been |
| 76 |
completed. |
| 77 |
|
| 78 |
On a final note the group discussed the benefits of |
| 79 |
demonstrating the system to jc (this was later backed up by |
| 80 |
iau). The group agreed to get the client looking better, the |
| 81 |
reporting tools ready, and the local clients in a decent |
| 82 |
state before this could happen. It was noted that the |
| 83 |
feedback from a potential end user could be invaluable to |
| 84 |
the project, but that time must be given to implement any |
| 85 |
changes resulting from this feedback. |
| 86 |
|
| 87 |
There will be a meeting as usual with Ian, but at the later |
| 88 |
time of 2.15pm (now a regular time). The next group meeting |
| 89 |
will be next Monday. |
