ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/projects/cms/documentation/minutes/minutes-20001113b.txt
Revision: 1.3
Committed: Wed Nov 15 00:33:45 2000 UTC (23 years, 11 months ago) by ajm
Content type: text/plain
Branch: MAIN
Changes since 1.2: +24 -18 lines
Log Message:
added tdb1's updates and other extras

File Contents

# Content
1 Minutes of Meeting, 13/11/2000 @ 14:00
2 Location: Eliot College, E3E room 8
3
4 Present: ajm4, tdb1
5 Absent: none
6
7 [tdb1: Documented by ajm4, comments added by tdb1.]
8
9 This meeting was between ajm4 and tdb1 to discuss and
10 possibly implement parts of the CORE and FilterManager
11 elements of the system.
12
13
14
15 Initial discussion was on the configuration system of the
16 CORE which has been partially completed to date. A key
17 decision that was made was that it will NOT be possible
18 for the elements of the system to update their own
19 configuration, as this will cause difficulties if the user
20 wants to use the file themseleves (ie, add comments). This
21 isn't seen to be a real problem though, as it was only going
22 to be a "funky" extra ;-)
23
24 [tdb1: this will also solve security issues with
25 unauthorised third parties changing settings.]
26
27
28 Next point was whether or not we would support elements
29 being able to be updated without restarting them, ie. a host
30 would be able to detect its configuration has changed and
31 adjust accordingly. The method chosen was to use the last
32 modified date stamp of the configuration file as an
33 indicator. When a Configuration object is passed to an
34 element of the system it can determine when the loaded
35 configuration was last edited. The element of the system
36 can then periodically (the period can be set in the
37 configuration ;-) ) ask the Configurator if its
38 configuration has been updated, and act accordingly. The
39 methods:
40
41 long Configuration.getLastModifed() and
42 boolean Configurator.isModified(String conf, long curTime)
43
44 where thus implemented and the configurator test class
45 modified to include a test of this system.
46
47 It should also be noted at this stage that a java 'long' is
48 defined as a 'long long' in the IDL->Java mapping.
49
50
51 The next item discussed was the CORBA IDL and general system
52 package structure. It was decided to use the ukc domain as
53 the root identifier for the project. Packages therefore
54 follow the naming:
55
56 uk.ac.ukc.iscream.<package>.<class>|<sub-package>
57
58 The IDL and currently implemented classes were updated to
59 refelect this change.
60
61
62
63 The next item to be discussed was the initial thinking and
64 possible implementation of the FilterManager. An initial
65 FilterManager class was fleshed out with hooks to the logger
66 and the configurator, it then creates a FilterListener class
67 which will listen for new Hosts trying to connect to the
68 system. It was NOT decided how Hosts should find the system
69 however a method similar to the WPAD system used to locate
70 web caches was suggested by tdb1.
71
72 A Host contacts the FilterManager to initialise itself and
73 obtain a host and port number of a Filter that it will talk
74 to. When the FilterListener is contacted by a host it spawns
75 a HostInit object to handle this intialisation. The first
76 thing a Host does is obtain its configuration, this is done
77 by the HostInit object obtaining the configuration of the
78 host on its behalf. An initial protocol of how this system
79 works is as follows (of course this is subject to later
80 alteration, but seemed like a "good idea at the time"):
81
82 Host FilterManager.HostInit
83 STARTCONFIG ->
84 <- OK | ERROR
85 LASTMODIFIED ->
86 <- LASTMODIFIED
87 DO {
88 PROPERTY ->
89 <- VALUE | ERROR
90 } UNTIL GOT CONFIG
91
92 ENDCONFIG ->
93 <- OK
94
95 If there is an ERROR returned after STARTCONFIG, this
96 indicates to the Host that there is no configuration
97 available for it at this time. It may be possible to
98 continue using default values, but this is up to the host
99 configuration. Again, this is not a certain feature and
100 should be discussed with other members of the group.
101
102 If the property section returns an ERROR then this indicates
103 to the host that that property requested doesn't exist, the
104 Host will then deal with this either by ending with an error
105 on the local system or by ignoring it if it can.
106
107 The above features were implemented.
108
109
110
111 The next item needed to be developed is an architecture for
112 FilterParent's and FilterChild's, as the next stage of Host
113 initialisation is to be passed a 'reference' to a
114 FilterChild. This 'reference' will be a server and a port
115 and not a reference in the CORBA or Java way of thinking.
116
117 It was noted that on a "heart beat" with the system, a Host
118 should check to see if its configuration has changed. If it
119 has it should then re-initialise itself. This will allow
120 configuration changes to be made to any part of the system
121 knowing that on the next "heart beat" the configuration will
122 take effect. A point to note about this is that if there is
123 an error in the configuration the Host will simply error and
124 die. What we may want (but still undecided) is a constant
125 retry until the config is ok. So the system administrator
126 will see in the logger destination that there has been an
127 error in this new configuration and can make changes to
128 rectify the problem, without having to interact with the
129 Host program itself.
130
131
132
133 All code generated was placed in the "experimental" tree of
134 CVS, awaiting approval from other group members. It should
135 also be noted that although CVS records tdb1 as the
136 'checker inner', it was infact ajm4...as he was the king of
137 code during this meeting ;-p
138
139 Many small bug fixes were made to the existing code.
140
141 It was also noted that there is a need for coding standards.
142
143 As we had reached an appropriate stage to end, and given the
144 late hour, it was decided to conclude the meeting. It was,
145 after all, nearly 7 hours of coding ;-)
146
147 Since this meeting took place tdb1 has produced Makefiles
148 to allow easy compiling and configuration of the code.
149
150
151 Meeting was concluded @ 20:45. Next meeting booked for 11:00
152 on Wednesday, until 12:30. Meeting with iau @ 13:30 on that
153 day.