i-scream documentation viewer

minutes-20001128.txt

Minutes of meeting 28/11/00 @ 1pm
Location: Eliot College, E3E room 8

Present: pjm2, tdb1
Absent: None

A small sub-meeting was held between Paul and Tim to discuss 
the plugin structure in the Filter, and some database design 
issues.

First to be discussed was the Filter plugin system. Paul has 
agreed to implement this setup. The following design was put 
forward, any objections should be noted at the next meeting.

A PluginManager will be in charge of handling the individual 
plugins, and will provide a single point of contact the the 
Filter system. The PluginManager will be constructed in the 
main method of the Filter, and a single reference passed to 
the three subcomponents - the FilterServant, UDPReader and 
TCPReader. These three in turn will pass the reference on to 
the FilterThread they create.

The FilterThread is currently the final point in the Filter 
that has the data. At present it just passes the original 
XML string on to it's parent. The PluginManager will be used 
just before this event occurs. It will provide a single 
method which can be called by the FilterThread. This method 
will take an XMLPacket object and return a boolean. The 
FilterThread will use this boolean value to decide whether 
to send the XML on to it's parent.

The idea behind having this single PluginManager object is 
that it will save recreating instances of the actual plugins 
each time a data item arrives. It might provide a method to 
reinitialise itself, but this has not been finalised.

The actual plugins themselves will implement a single Java 
interface. The PluginManager will hold an array of these 
objects which it will pass the XMLPacket through in order. 
These plugins will reside in a subdirectory, hopefully, and 
will either all be loaded, or be configured in the central 
ConfigurationManager.

The main issue with this is concurrency. Obviously only 
having one instance of the PluginManager could cause 
problems with three threads trying to call it. This should 
be discussed with the group, as threads can be a tricky 
thing to get absolutely right.

Other issues discussed include the database design. Paul has 
produced a design for the database tables, which is 
available in CVS for the group to examine. Some issues arose 
with the SQL insertion routine, and whether or not a lock 
would be required. This should be investigated further.

Paul also agreed to look into the Java side of the database 
system. This would be a single module that would link in to 
the root filter. The root filter would pass the raw XML 
strings into this module, which would in turn decode them 
and store them in the database.

This brought about another issue, namely the XML decoding 
classes. These are currently used in both the filter and 
root filter. It was decided that they would not be needed in 
the root filter as it would just pass the raw XML data. This 
only leaves one point they're needed, at present. However, 
this will change as the database interface will require them 
and no doubt the client side will too. It was suggested that 
these should be moved into a seperate package that could be 
used by the whole system.

Packaging of classes is an issue which should be discussed 
at the next meeting, and then put in place.

Other group members should have read these minutes prior to 
the next meeting if possible.