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, 11 months 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.
#	Content
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. This
28	thought was rejected by iau in the meeting.
29
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	The whole issue of packet content is more of a host & client
38	design issue than a server issue.
39
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
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