| 1 |
Minutes of meeting 28/11/00 @ 1pm |
| 2 |
Location: Eliot College, E3E room 8 |
| 3 |
|
| 4 |
Present: pjm2, tdb1 |
| 5 |
Absent: None |
| 6 |
|
| 7 |
A small sub-meeting was held between Paul and Tim to discuss |
| 8 |
the plugin structure in the Filter, and some database design |
| 9 |
issues. |
| 10 |
|
| 11 |
First to be discussed was the Filter plugin system. Paul has |
| 12 |
agreed to implement this setup. The following design was put |
| 13 |
forward, any objections should be noted at the next meeting. |
| 14 |
|
| 15 |
A PluginManager will be in charge of handling the individual |
| 16 |
plugins, and will provide a single point of contact the the |
| 17 |
Filter system. The PluginManager will be constructed in the |
| 18 |
main method of the Filter, and a single reference passed to |
| 19 |
the three subcomponents - the FilterServant, UDPReader and |
| 20 |
TCPReader. These three in turn will pass the reference on to |
| 21 |
the FilterThread they create. |
| 22 |
|
| 23 |
The FilterThread is currently the final point in the Filter |
| 24 |
that has the data. At present it just passes the original |
| 25 |
XML string on to it's parent. The PluginManager will be used |
| 26 |
just before this event occurs. It will provide a single |
| 27 |
method which can be called by the FilterThread. This method |
| 28 |
will take an XMLPacket object and return a boolean. The |
| 29 |
FilterThread will use this boolean value to decide whether |
| 30 |
to send the XML on to it's parent. |
| 31 |
|
| 32 |
The idea behind having this single PluginManager object is |
| 33 |
that it will save recreating instances of the actual plugins |
| 34 |
each time a data item arrives. It might provide a method to |
| 35 |
reinitialise itself, but this has not been finalised. |
| 36 |
|
| 37 |
The actual plugins themselves will implement a single Java |
| 38 |
interface. The PluginManager will hold an array of these |
| 39 |
objects which it will pass the XMLPacket through in order. |
| 40 |
These plugins will reside in a subdirectory, hopefully, and |
| 41 |
will either all be loaded, or be configured in the central |
| 42 |
ConfigurationManager. |
| 43 |
|
| 44 |
The main issue with this is concurrency. Obviously only |
| 45 |
having one instance of the PluginManager could cause |
| 46 |
problems with three threads trying to call it. This should |
| 47 |
be discussed with the group, as threads can be a tricky |
| 48 |
thing to get absolutely right. |
| 49 |
|
| 50 |
Other issues discussed include the database design. Paul has |
| 51 |
produced a design for the database tables, which is |
| 52 |
available in CVS for the group to examine. Some issues arose |
| 53 |
with the SQL insertion routine, and whether or not a lock |
| 54 |
would be required. This should be investigated further. |
| 55 |
|
| 56 |
Paul also agreed to look into the Java side of the database |
| 57 |
system. This would be a single module that would link in to |
| 58 |
the root filter. The root filter would pass the raw XML |
| 59 |
strings into this module, which would in turn decode them |
| 60 |
and store them in the database. |
| 61 |
|
| 62 |
This brought about another issue, namely the XML decoding |
| 63 |
classes. These are currently used in both the filter and |
| 64 |
root filter. It was decided that they would not be needed in |
| 65 |
the root filter as it would just pass the raw XML data. This |
| 66 |
only leaves one point they're needed, at present. However, |
| 67 |
this will change as the database interface will require them |
| 68 |
and no doubt the client side will too. It was suggested that |
| 69 |
these should be moved into a seperate package that could be |
| 70 |
used by the whole system. |
| 71 |
|
| 72 |
Packaging of classes is an issue which should be discussed |
| 73 |
at the next meeting, and then put in place. |
| 74 |
|
| 75 |
Other group members should have read these minutes prior to |
| 76 |
the next meeting if possible. |
