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. This 
thought was rejected by iau in the meeting.

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.

It was mentioned that the logging system should be able to 
deal with verbosity levels, in a similar way to JacORB. This 
would allow trivial messages to be hidden most of the time. 
The possibility of multiple loggers might also want to be 
consider (eg. file log with high verbosity, and screen log 
with low verbosity, running in parallel).

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.4
Committed:	Wed Nov 15 23:51:38 2000 UTC (24 years ago) by tdb
Content type:	text/plain
Branch:	MAIN
CVS Tags:	PROJECT_COMPLETION, HEAD
Changes since 1.3:	+9 -1 lines
Log Message:	A few small additions.
#	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	tdb	1.4	corba. This would solve a lot of local copy problems. This
28			thought was rejected by iau in the meeting.
29	ab11	1.1
30			Discussion of whether UDP packets should be numbered or
31			timestamped proved controversal. In the end it was decided
32			that each UDP packet should contain both a Sequence number
33			and a timestamp (as defined by the host). It is therefore
34			important that the host's time is setup accurately by the
35			sysadmin.
36
37	tdb	1.3	The whole issue of packet content is more of a host & client
38			design issue than a server issue.
39	tdb	1.4
40			It was mentioned that the logging system should be able to
41			deal with verbosity levels, in a similar way to JacORB. This
42			would allow trivial messages to be hidden most of the time.
43			The possibility of multiple loggers might also want to be
44			consider (eg. file log with high verbosity, and screen log
45			with low verbosity, running in parallel).
46	tdb	1.3
47			Meeting concluded @ 12:40
48
49			Meeting continued @ 12:45 by a tree
50			Present: ajm4, pjm2, tdb1
51
52			Discussion continued about the design of the filter system.
53			The whole issue of how and where packets will be stored
54			within the system needed clearing up before implementation
55			could continue.
56
57			It was noted that the key function of the filter (given it's
58			called a "filter") is to remove any packets of data it sees
59			fit. With this in mind it was decided that the data could be
60			passed on in text (or rather XML) format through the child
61			filters.
62
63			This would work as follows in a child filter. Data would be
64			recieved by one of two means, UDP or CORBA. The hosts would
65			be sending UDP to the filter, and other "up-stream" child
66			filters would send over CORBA. Regardless, it will always be
67			the same content - a String of XML. In essence this means
68			that the filter will be sending and receiving exactly the
69			same string of XML - without any conversion required.
70			Internally it may be verified through "plug-ins" to see if
71			it should be dropped, but this would just be a series of
72			independant tests. Finally the string will be passed on if
73			the plug-ins allow.
74
75			This allows a chain of child filters going on and on in a
76			tree-like fashion, which is what our original design
77			permitted.
78
79			Finally, the parent filter will recieve all the data from
80			the child filters, and turn them into XMLPackets. These
81			packets will be stored in some kind of data structure to be
82			accessed by the various parts of the system.
83
84			This solves many of our key problems.
85
86			Meeting concluded @ 13:25
87
88			Meeting continued @ 13:40 with iau
89
90			iau briefly suggested that we alter the location of the
91			database in our system. He suggested moving this into the
92			parent filter, and then having the data passed straight on
93			to the client interface.
94
95			Nothing firm was decided, but it should be analysed further.
96
97			Meeting concluded @ 13:55