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