1 |
tdb |
1.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. |