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