i-scream documentation viewer
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.
