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.
