1 |
ajm |
1.1 |
Minutes of Meeting, 13/11/2000 @ 14:00 |
2 |
tdb |
1.2 |
Location: Eliot College, E3E room 8 |
3 |
ajm |
1.1 |
|
4 |
|
|
Present: ajm4, tdb1 |
5 |
|
|
Absent: none |
6 |
|
|
|
7 |
tdb |
1.2 |
[tdb1: Documented by ajm4, comments added by tdb1.] |
8 |
|
|
|
9 |
ajm |
1.1 |
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 |
tdb |
1.2 |
[tdb1: this will also solve security issues with |
25 |
|
|
unauthorised third parties changing settings.] |
26 |
|
|
|
27 |
|
|
|
28 |
ajm |
1.1 |
Next point was whether or not we would support elements |
29 |
tdb |
1.2 |
being able to be updated without restarting them, ie. a host |
30 |
ajm |
1.1 |
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 |
tdb |
1.2 |
long Configuration.getLastModifed() and |
42 |
|
|
boolean Configurator.isModified(String conf, long curTime) |
43 |
ajm |
1.1 |
|
44 |
|
|
where thus implemented and the configurator test class |
45 |
|
|
modified to include a test of this system. |
46 |
|
|
|
47 |
ajm |
1.3 |
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 |
ajm |
1.1 |
|
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 |
tdb |
1.2 |
host on its behalf. An initial protocol of how this system |
79 |
ajm |
1.3 |
works is as follows (of course this is subject to later |
80 |
|
|
alteration, but seemed like a "good idea at the time"): |
81 |
tdb |
1.2 |
|
82 |
ajm |
1.1 |
Host FilterManager.HostInit |
83 |
|
|
STARTCONFIG -> |
84 |
tdb |
1.2 |
<- OK | ERROR |
85 |
ajm |
1.1 |
LASTMODIFIED -> |
86 |
tdb |
1.2 |
<- LASTMODIFIED |
87 |
ajm |
1.1 |
DO { |
88 |
|
|
PROPERTY -> |
89 |
tdb |
1.2 |
<- VALUE | ERROR |
90 |
ajm |
1.1 |
} UNTIL GOT CONFIG |
91 |
|
|
|
92 |
|
|
ENDCONFIG -> |
93 |
tdb |
1.2 |
<- OK |
94 |
ajm |
1.1 |
|
95 |
ajm |
1.3 |
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 |
ajm |
1.1 |
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 |
ajm |
1.3 |
The above features were implemented. |
108 |
|
|
|
109 |
tdb |
1.2 |
|
110 |
ajm |
1.1 |
|
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 |
ajm |
1.3 |
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 |
ajm |
1.1 |
|
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 |
ajm |
1.3 |
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 |
ajm |
1.1 |
|
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 |
ajm |
1.3 |
late hour, it was decided to conclude the meeting. It was, |
145 |
|
|
after all, nearly 7 hours of coding ;-) |
146 |
tdb |
1.2 |
|
147 |
ajm |
1.3 |
Since this meeting took place tdb1 has produced Makefiles |
148 |
|
|
to allow easy compiling and configuration of the code. |
149 |
tdb |
1.2 |
|
150 |
ajm |
1.1 |
|
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. |