i-scream documentation viewer

minutes-20001113.txt 

Minutes of Meeting, 13/11/2000 @ 9:00
Location: UKC Computer Science Meeting Room

Present: ab11, pjm2, tdb1
Absent: ajm4


The communications between host and server were discussed 
yet again. Paul argued that the TCP communications were 
unnecessary, and UDP would suffice. Tim pointed out that the 
general unreliability of UDP would make it hard for the 
system to know whether a host had actually gone down, or 
whether it was a network problem. Tim also pointed out that 
the UDP packets may require sequencing, so the server knows 
whether packets were missed - for alerting purposes.

In the end it was decided that a combination would be used, 
with TCP used for heartbeats alongside the regular UDP 
communications. Different alerts could be raised depending 
on whether UDP packets weren't arriving, or the TCP 
heartbeat fails (the latter being considered worse).

Discussion continued with Paul outlining the basic situation 
with XML parsing. It was noted that various external java 
classes would be required for parsing (SAX, and javax...). 
This should not be a problem.

Finally the XMLPacket was discussed. It was noted that the 
XML data must somehow be laid out in the XMLPacket, 
retaining it's structure. The following was suggested, with 
the data being stored as tuples in the XMLPacket.

[XML]

<data>
  <value1>val1</value1>
  <sub1>
    <value2>val2</value2>
    <value3>val3</value3>
  </sub1>
</data>

[XMLPacket]

"data.value1", "val1"
"data.sub1.value2", "val2"
"data.sub1.value3", "val3"

This format makes it easy for the "end client" to extract 
information, only knowing the format of the XML data. This 
helps to ensure consistency across the system.

It was decided that some kind of Hash would be the quickest 
way of storing (and accessing) these tuples of data. The 
group agreed this idea would be best.

The lifetime and location of the XMLPacket is still an 
uncertain area. We must ensure they are left for the Garbage 
Collector when they are finished with.

Prior to the next meeting Paul will continue to investigate 
the XML parsing, and work on that side of the Filter. Ash 
will continue work on the host side (still in Java). AJ & 
Tim will collaborate on the FilterManager, ParentFilter, and 
possibly the CORBA side of Paul's filter system.

Finally, the group members (that were present) voted 
unanimously that AJ will be doing the hard parts of the C++ 
bits in the host. :)

Meeting was concluded @ 11:00. Next meeting booked for 11:00 
on Wednesday, until 12:30. Meeting with iau @ 13:30 on that 
day.