ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/projects/cms/documentation/minutes/minutes-20010129.txt
Revision: 1.1
Committed: Thu Feb 1 01:57:20 2001 UTC (23 years, 2 months ago) by tdb
Content type: text/plain
Branch: MAIN
CVS Tags: PROJECT_COMPLETION, HEAD
Log Message:
Minutes from 29/01/2001.

File Contents

# Content
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.