| 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. |
