| 1 |
Minutes of meeting 15/11/00 @ 11am |
| 2 |
Location: UKC Computer Science Meeting Room |
| 3 |
|
| 4 |
Present: ab11, ajm4, pjm2, tdb1 |
| 5 |
Absent: None |
| 6 |
|
| 7 |
Meeting postponed until firealarm finishes. It is noted that |
| 8 |
Ash and Paul would have been burnt alive if there was a real |
| 9 |
fire. |
| 10 |
|
| 11 |
Meeting re-started at 11:20am. |
| 12 |
|
| 13 |
Discussed the XML packet life problem. This has been |
| 14 |
identified as a problem because corba passes references to |
| 15 |
objects making it hard to determine when the object should |
| 16 |
be distroyed. |
| 17 |
|
| 18 |
Paul begins implementation of a quotes page. |
| 19 |
|
| 20 |
Paul suggests that packets should be stored in a queue |
| 21 |
structure, with 2 integers indicating how far through the |
| 22 |
queue each accessing function has got (from the start of the |
| 23 |
queue). This should be more efficient than storing flags |
| 24 |
inside each of the XML packet objects. |
| 25 |
|
| 26 |
Someone needs to find out if you can 'clone' an object over |
| 27 |
corba. This would solve a lot of local copy problems. |
| 28 |
|
| 29 |
Discussion of whether UDP packets should be numbered or |
| 30 |
timestamped proved controversal. In the end it was decided |
| 31 |
that each UDP packet should contain both a Sequence number |
| 32 |
and a timestamp (as defined by the host). It is therefore |
| 33 |
important that the host's time is setup accurately by the |
| 34 |
sysadmin. |
| 35 |
|
| 36 |
The whole issue of packet content is more of a host & client |
| 37 |
design issue than a server issue. |
| 38 |
|
| 39 |
Meeting concluded @ 12:40 |
| 40 |
|
| 41 |
Meeting continued @ 12:45 by a tree |
| 42 |
Present: ajm4, pjm2, tdb1 |
| 43 |
|
| 44 |
Discussion continued about the design of the filter system. |
| 45 |
The whole issue of how and where packets will be stored |
| 46 |
within the system needed clearing up before implementation |
| 47 |
could continue. |
| 48 |
|
| 49 |
It was noted that the key function of the filter (given it's |
| 50 |
called a "filter") is to remove any packets of data it sees |
| 51 |
fit. With this in mind it was decided that the data could be |
| 52 |
passed on in text (or rather XML) format through the child |
| 53 |
filters. |
| 54 |
|
| 55 |
This would work as follows in a child filter. Data would be |
| 56 |
recieved by one of two means, UDP or CORBA. The hosts would |
| 57 |
be sending UDP to the filter, and other "up-stream" child |
| 58 |
filters would send over CORBA. Regardless, it will always be |
| 59 |
the same content - a String of XML. In essence this means |
| 60 |
that the filter will be sending and receiving exactly the |
| 61 |
same string of XML - without any conversion required. |
| 62 |
Internally it may be verified through "plug-ins" to see if |
| 63 |
it should be dropped, but this would just be a series of |
| 64 |
independant tests. Finally the string will be passed on if |
| 65 |
the plug-ins allow. |
| 66 |
|
| 67 |
This allows a chain of child filters going on and on in a |
| 68 |
tree-like fashion, which is what our original design |
| 69 |
permitted. |
| 70 |
|
| 71 |
Finally, the parent filter will recieve all the data from |
| 72 |
the child filters, and turn them into XMLPackets. These |
| 73 |
packets will be stored in some kind of data structure to be |
| 74 |
accessed by the various parts of the system. |
| 75 |
|
| 76 |
This solves many of our key problems. |
| 77 |
|
| 78 |
Meeting concluded @ 13:25 |
| 79 |
|
| 80 |
Meeting continued @ 13:40 with iau |
| 81 |
|
| 82 |
iau briefly suggested that we alter the location of the |
| 83 |
database in our system. He suggested moving this into the |
| 84 |
parent filter, and then having the data passed straight on |
| 85 |
to the client interface. |
| 86 |
|
| 87 |
Nothing firm was decided, but it should be analysed further. |
| 88 |
|
| 89 |
Meeting concluded @ 13:55 |
