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
Log Message:	Minutes from 20/11/2000.
#	User	Rev	Content
1	tdb	1.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.