ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
Revision: 1.1
Committed: Mon Nov 13 13:44:43 2000 UTC (23 years, 7 months ago) by tdb
Content type: text/plain
Branch: MAIN
Log Message:
Minutes from meeting on 13 November 2000.

File Contents

# Content
1 Minutes of Meeting, 13/11/2000 @ 9:00
2 Location: UKC Computer Science Meeting Room
4 Present: ab11, pjm2, tdb1
5 Absent: ajm4
8 The communications between host and server were discussed
9 yet again. Paul argued that the TCP communications were
10 unnecessary, and UDP would suffice. Tim pointed out that the
11 general unreliability of UDP would make it hard for the
12 system to know whether a host had actually gone down, or
13 whether it was a network problem. Tim also pointed out that
14 the UDP packets may require sequencing, so the server knows
15 whether packets were missed - for alerting purposes.
17 In the end it was decided that a combination would be used,
18 with TCP used for heartbeats alongside the regular UDP
19 communications. Different alerts could be raised depending
20 on whether UDP packets weren't arriving, or the TCP
21 heartbeat fails (the latter being considered worse).
23 Discussion continued with Paul outlining the basic situation
24 with XML parsing. It was noted that various external java
25 classes would be required for parsing (SAX, and javax...).
26 This should not be a problem.
28 Finally the XMLPacket was discussed. It was noted that the
29 XML data must somehow be laid out in the XMLPacket,
30 retaining it's structure. The following was suggested, with
31 the data being stored as tuples in the XMLPacket.
33 [XML]
35 <data>
36 <value1>val1</value1>
37 <sub1>
38 <value2>val2</value2>
39 <value3>val3</value3>
40 </sub1>
41 </data>
43 [XMLPacket]
45 "data.value1", "val1"
46 "data.sub1.value2", "val2"
47 "data.sub1.value3", "val3"
49 This format makes it easy for the "end client" to extract
50 information, only knowing the format of the XML data. This
51 helps to ensure consistency across the system.
53 It was decided that some kind of Hash would be the quickest
54 way of storing (and accessing) these tuples of data. The
55 group agreed this idea would be best.
57 The lifetime and location of the XMLPacket is still an
58 uncertain area. We must ensure they are left for the Garbage
59 Collector when they are finished with.
61 Prior to the next meeting Paul will continue to investigate
62 the XML parsing, and work on that side of the Filter. Ash
63 will continue work on the host side (still in Java). AJ &
64 Tim will collaborate on the FilterManager, ParentFilter, and
65 possibly the CORBA side of Paul's filter system.
67 Finally, the group members (that were present) voted
68 unanimously that AJ will be doing the hard parts of the C++
69 bits in the host. :)
71 Meeting was concluded @ 11:00. Next meeting booked for 11:00
72 on Wednesday, until 12:30. Meeting with iau @ 13:30 on that
73 day.