documentation/minutes/minutes-20001115.txt

Minutes of meeting 15/11/00 @ 11am
Location: UKC Computer Science Meeting Room

Present: ab11, ajm4, pjm2, tdb1
Absent: None

Meeting postponed until firealarm finishes. It is noted that
Ash and Paul would have been burnt alive if there was a real 
fire. 

Meeting re-started at 11:20am. 

Discussed the XML packet life problem. This has been 
identified as a problem because corba passes references to 
objects making it hard to determine when the object should 
be distroyed.

Paul begins implementation of a quotes page.

Paul suggests that packets should be stored in a queue
structure, with 2 integers indicating how far through the 
queue each accessing function has got (from the start of the 
queue). This should be more efficient than storing flags 
inside each of the XML packet objects.

Someone needs to find out if you can 'clone' an object over 
corba. This would solve a lot of local copy problems.

Discussion of whether UDP packets should be numbered or
timestamped proved controversal. In the end it was decided
that each UDP packet should contain both a Sequence number
and a timestamp (as defined by the host). It is therefore
important that the host's time is setup accurately by the
sysadmin.

The whole issue of packet content is more of a host & client 
design issue than a server issue.

Meeting concluded @ 12:40

Meeting continued @ 12:45 by a tree
Present: ajm4, pjm2, tdb1

Discussion continued about the design of the filter system. 
The whole issue of how and where packets will be stored 
within the system needed clearing up before implementation 
could continue.

It was noted that the key function of the filter (given it's 
called a "filter") is to remove any packets of data it sees 
fit. With this in mind it was decided that the data could be 
passed on in text (or rather XML) format through the child 
filters.

This would work as follows in a child filter. Data would be 
recieved by one of two means, UDP or CORBA. The hosts would 
be sending UDP to the filter, and other "up-stream" child 
filters would send over CORBA. Regardless, it will always be 
the same content - a String of XML. In essence this means 
that the filter will be sending and receiving exactly the 
same string of XML - without any conversion required. 
Internally it may be verified through "plug-ins" to see if 
it should be dropped, but this would just be a series of 
independant tests. Finally the string will be passed on if 
the plug-ins allow.

This allows a chain of child filters going on and on in a 
tree-like fashion, which is what our original design 
permitted.

Finally, the parent filter will recieve all the data from 
the child filters, and turn them into XMLPackets. These 
packets will be stored in some kind of data structure to be 
accessed by the various parts of the system.

This solves many of our key problems.

Meeting concluded @ 13:25

Meeting continued @ 13:40 with iau

iau briefly suggested that we alter the location of the 
database in our system. He suggested moving this into the 
parent filter, and then having the data passed straight on 
to the client interface.

Nothing firm was decided, but it should be analysed further.

Meeting concluded @ 13:55
Revision:	1.3
Committed:	Wed Nov 15 19:10:14 2000 UTC (23 years, 11 months ago) by tdb
Content type:	text/plain
Branch:	MAIN
Changes since 1.2:	+67 -14 lines
Log Message:	Added some further minutes from later meetings.
#	User	Rev	Content
1	ab11	1.1	Minutes of meeting 15/11/00 @ 11am
2	ab11	1.2	Location: UKC Computer Science Meeting Room
3	ab11	1.1
4			Present: ab11, ajm4, pjm2, tdb1
5			Absent: None
6
7	tdb	1.3	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	ab11	1.1
11			Meeting re-started at 11:20am.
12
13	tdb	1.3	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	ab11	1.1
18			Paul begins implementation of a quotes page.
19
20			Paul suggests that packets should be stored in a queue
21	tdb	1.3	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	ab11	1.1
26	tdb	1.3	Someone needs to find out if you can 'clone' an object over
27			corba. This would solve a lot of local copy problems.
28	ab11	1.1
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	tdb	1.3	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