ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/projects/cms/documentation/minutes/minutes-20001120.txt
Revision: 1.1
Committed: Mon Nov 20 19:17:18 2000 UTC (23 years, 4 months ago) by tdb
Content type: text/plain
Branch: MAIN
CVS Tags: PROJECT_COMPLETION, HEAD
Log Message:
Minutes from 20/11/2000.

File Contents

# Content
1 Minutes of meeting 20/11/00 @ 2pm
2 Location: UKC Computer Science Meeting Room
3
4 Present: ab11, ajm4, pjm2, tdb1
5 Absent: None
6
7 AJ & Tim reported back about the latest modifications to the
8 CORE of the system. The main point was the hierarchical
9 layering of includes within the configuration files. The
10 following format was decided;
11
12 include = file1.conf,file2.conf,file3.conf
13
14 This line would be in the root configuration file. Each
15 include would be processed in turn, checking to see if they
16 have any includes. All of these would then be brought
17 together into one list.
18
19 Assuming the root configuration above is root.conf, and that
20 each of the includes has two includes, we would get the
21 following list of configuration files.
22
23 root.conf, file1.conf, file1a.conf, file1b.conf,
24 file2.conf, file2a.conf, file2b.conf, file3.conf,
25 file3a.conf, file3b.conf
26
27 When a property is requested each of these files will be
28 checked, in order, until the requested property is found. It
29 was noted that this would allow a very manageable and
30 maintainable setup for the configuration system.
31
32 NB: The Configurator is now known as the
33 ConfigurationManager in the CORE.
34
35 Paul reported back that the XML/UDP stuff was finished, and
36 a few bugs had been fixed. Ash reported back that the Java
37 host application was coming along.
38
39
40 Next to be discussed was the hierarchical filter system, and
41 how this would all be tided together into the existing
42 system. Firstly, the system was defined as such.
43
44 Each Filter object will listen for UDP packets (containing
45 an XML string) on a given port, and they will also have a
46 method that can be invoked (passing an xml string). Both of
47 these ways of receiving an XML string result in the same
48 process of events.
49
50 The Filter then passes the XML data through a chain of
51 events that will ultimately dictate whether the data will be
52 passed on. The Filter has a "parent" reference to another
53 filter, to be contacting over CORBA. This parent could be
54 the root Filter, or indeed just another filter. The data, if
55 it hasn't been filtered out, will be delivered to the
56 parent.
57
58 Internally a filter has a series of plugins. These plugins
59 will be given the XML data (probably through an XMLPacket
60 object) and will return a boolean. True indicates the packet
61 is fine, False indicates it should be rejected. As soon as a
62 plugin returns false the packet is dropped.
63
64 Filters will obtain their configuration over CORBA from the
65 ConfigurationManager. This will include their parent filter
66 reference, and possibly which port to listen on.
67
68
69 It was decided that AJ & Tim would sort out the few areas
70 left in the CORE, and then prepare a base Filter (just the
71 CORBA related stuff). Paul would then attach his UDP/XML
72 code onto this to produce an almost complete Filter. This
73 should hopefully be done by the next meeting, when
74 implementation of plugins can be arranged.
75
76
77 Another issue that needed addressing was the effect CORBA
78 referencing has on GarbageCollection. Ian has already said
79 he'll look into it, but Paul has offered to question Richard
80 Jones about it.
81
82
83 In terms of Goals it was decided that by next Monday the
84 basics of the Server should be written (this includes the
85 CORE and the Filter system). For the remaining three weeks
86 it was put forward that we should attempt to have the Client
87 Interface written at a basic level, the database setup
88 sorted, and a basic client running. A good Java host should
89 also be completed. This target is important as there is a
90 lot more to do during the next term.
91
92
93 The next meeting is planned and booked for Wednesday 22nd,
94 between 3pm and 5pm. Group members should see above for what
95 they should aim to have completed by this date.