ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
Revision: 1.2
Committed: Thu Nov 30 23:55:16 2000 UTC (23 years, 6 months ago) by tdb
Content type: text/plain
Branch: MAIN
Changes since 1.1: +1 -1 lines
Log Message:
Appears I got the date wrong.

File Contents

# Content
1 Minutes of meeting 28/11/00 @ 1pm
2 Location: Eliot College, E3E room 8
4 Present: pjm2, tdb1
5 Absent: None
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
72 Packaging of classes is an issue which should be discussed
73 at the next meeting, and then put in place.
75 Other group members should have read these minutes prior to
76 the next meeting if possible.