1 |
Minutes of Meeting, 13/11/2000 @ 9:00 |
2 |
Location: UKC Computer Science Meeting Room |
3 |
|
4 |
Present: ab11, pjm2, tdb1 |
5 |
Absent: ajm4 |
6 |
|
7 |
|
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. |
16 |
|
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). |
22 |
|
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. |
27 |
|
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. |
32 |
|
33 |
[XML] |
34 |
|
35 |
<data> |
36 |
<value1>val1</value1> |
37 |
<sub1> |
38 |
<value2>val2</value2> |
39 |
<value3>val3</value3> |
40 |
</sub1> |
41 |
</data> |
42 |
|
43 |
[XMLPacket] |
44 |
|
45 |
"data.value1", "val1" |
46 |
"data.sub1.value2", "val2" |
47 |
"data.sub1.value3", "val3" |
48 |
|
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. |
52 |
|
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. |
56 |
|
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. |
60 |
|
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. |
66 |
|
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. :) |
70 |
|
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. |