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