documentation/minutes/minutes-20001120.txt

Minutes of meeting 20/11/00 @ 2pm
Location: UKC Computer Science Meeting Room

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

AJ & Tim reported back about the latest modifications to the 
CORE of the system. The main point was the hierarchical 
layering of includes within the configuration files. The 
following format was decided;

include = file1.conf,file2.conf,file3.conf

This line would be in the root configuration file. Each 
include would be processed in turn, checking to see if they 
have any includes. All of these would then be brought 
together into one list.

Assuming the root configuration above is root.conf, and that 
each of the includes has two includes, we would get the 
following list of configuration files.

  root.conf, file1.conf, file1a.conf, file1b.conf,
  file2.conf, file2a.conf, file2b.conf, file3.conf, 
  file3a.conf, file3b.conf

When a property is requested each of these files will be 
checked, in order, until the requested property is found. It 
was noted that this would allow a very manageable and 
maintainable setup for the configuration system.

NB: The Configurator is now known as the 
    ConfigurationManager in the CORE.

Paul reported back that the XML/UDP stuff was finished, and 
a few bugs had been fixed. Ash reported back that the Java 
host application was coming along.


Next to be discussed was the hierarchical filter system, and 
how this would all be tided together into the existing 
system. Firstly, the system was defined as such.

Each Filter object will listen for UDP packets (containing 
an XML string) on a given port, and they will also have a 
method that can be invoked (passing an xml string). Both of 
these ways of receiving an XML string result in the same 
process of events.

The Filter then passes the XML data through a chain of 
events that will ultimately dictate whether the data will be 
passed on. The Filter has a "parent" reference to another 
filter, to be contacting over CORBA. This parent could be 
the root Filter, or indeed just another filter. The data, if 
it hasn't been filtered out, will be delivered to the 
parent.

Internally a filter has a series of plugins. These plugins 
will be given the XML data (probably through an XMLPacket 
object) and will return a boolean. True indicates the packet 
is fine, False indicates it should be rejected. As soon as a 
plugin returns false the packet is dropped.

Filters will obtain their configuration over CORBA from the 
ConfigurationManager. This will include their parent filter 
reference, and possibly which port to listen on.


It was decided that AJ & Tim would sort out the few areas 
left in the CORE, and then prepare a base Filter (just the 
CORBA related stuff). Paul would then attach his UDP/XML 
code onto this to produce an almost complete Filter. This 
should hopefully be done by the next meeting, when 
implementation of plugins can be arranged.


Another issue that needed addressing was the effect CORBA 
referencing has on GarbageCollection. Ian has already said 
he'll look into it, but Paul has offered to question Richard 
Jones about it.


In terms of Goals it was decided that by next Monday the 
basics of the Server should be written (this includes the 
CORE and the Filter system). For the remaining three weeks 
it was put forward that we should attempt to have the Client 
Interface written at a basic level, the database setup 
sorted, and a basic client running. A good Java host should 
also be completed. This target is important as there is a 
lot more to do during the next term.


The next meeting is planned and booked for Wednesday 22nd, 
between 3pm and 5pm. Group members should see above for what 
they should aim to have completed by this date.
Revision:	1.1
Committed:	Mon Nov 20 19:17:18 2000 UTC (23 years, 11 months ago) by tdb
Content type:	text/plain
Branch:	MAIN
CVS Tags:	PROJECT_COMPLETION, HEAD
Error occurred while calculating annotation data.
Log Message:	Minutes from 20/11/2000.
#	Content
1	Minutes of meeting 20/11/00 @ 2pm
2	Location: UKC Computer Science Meeting Room
3
4	Present: ab11, ajm4, pjm2, tdb1
5	Absent: None
6
7	AJ & Tim reported back about the latest modifications to the
8	CORE of the system. The main point was the hierarchical
9	layering of includes within the configuration files. The
10	following format was decided;
11
12	include = file1.conf,file2.conf,file3.conf
13
14	This line would be in the root configuration file. Each
15	include would be processed in turn, checking to see if they
16	have any includes. All of these would then be brought
17	together into one list.
18
19	Assuming the root configuration above is root.conf, and that
20	each of the includes has two includes, we would get the
21	following list of configuration files.
22
23	root.conf, file1.conf, file1a.conf, file1b.conf,
24	file2.conf, file2a.conf, file2b.conf, file3.conf,
25	file3a.conf, file3b.conf
26
27	When a property is requested each of these files will be
28	checked, in order, until the requested property is found. It
29	was noted that this would allow a very manageable and
30	maintainable setup for the configuration system.
31
32	NB: The Configurator is now known as the
33	ConfigurationManager in the CORE.
34
35	Paul reported back that the XML/UDP stuff was finished, and
36	a few bugs had been fixed. Ash reported back that the Java
37	host application was coming along.
38
39
40	Next to be discussed was the hierarchical filter system, and
41	how this would all be tided together into the existing
42	system. Firstly, the system was defined as such.
43
44	Each Filter object will listen for UDP packets (containing
45	an XML string) on a given port, and they will also have a
46	method that can be invoked (passing an xml string). Both of
47	these ways of receiving an XML string result in the same
48	process of events.
49
50	The Filter then passes the XML data through a chain of
51	events that will ultimately dictate whether the data will be
52	passed on. The Filter has a "parent" reference to another
53	filter, to be contacting over CORBA. This parent could be
54	the root Filter, or indeed just another filter. The data, if
55	it hasn't been filtered out, will be delivered to the
56	parent.
57
58	Internally a filter has a series of plugins. These plugins
59	will be given the XML data (probably through an XMLPacket
60	object) and will return a boolean. True indicates the packet
61	is fine, False indicates it should be rejected. As soon as a
62	plugin returns false the packet is dropped.
63
64	Filters will obtain their configuration over CORBA from the
65	ConfigurationManager. This will include their parent filter
66	reference, and possibly which port to listen on.
67
68
69	It was decided that AJ & Tim would sort out the few areas
70	left in the CORE, and then prepare a base Filter (just the
71	CORBA related stuff). Paul would then attach his UDP/XML
72	code onto this to produce an almost complete Filter. This
73	should hopefully be done by the next meeting, when
74	implementation of plugins can be arranged.
75
76
77	Another issue that needed addressing was the effect CORBA
78	referencing has on GarbageCollection. Ian has already said
79	he'll look into it, but Paul has offered to question Richard
80	Jones about it.
81
82
83	In terms of Goals it was decided that by next Monday the
84	basics of the Server should be written (this includes the
85	CORE and the Filter system). For the remaining three weeks
86	it was put forward that we should attempt to have the Client
87	Interface written at a basic level, the database setup
88	sorted, and a basic client running. A good Java host should
89	also be completed. This target is important as there is a
90	lot more to do during the next term.
91
92
93	The next meeting is planned and booked for Wednesday 22nd,
94	between 3pm and 5pm. Group members should see above for what
95	they should aim to have completed by this date.