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