documentation/minutes/minutes-20001128.txt

Minutes of meeting 27/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.
Revision:	1.1
Committed:	Tue Nov 28 21:02:36 2000 UTC (24 years ago) by tdb
Content type:	text/plain
Branch:	MAIN
Log Message:	Added Minutes from the sub-meeting on 28/11/2000.
#	User	Rev	Content
1	tdb	1.1	Minutes of meeting 27/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.