--- projects/cms/documentation/minutes/minutes-20001113b.txt 2000/11/15 00:01:05 1.1 +++ projects/cms/documentation/minutes/minutes-20001113b.txt 2000/11/15 00:19:49 1.2 @@ -1,9 +1,11 @@ Minutes of Meeting, 13/11/2000 @ 14:00 -Location: Eliot College, room E3E +Location: Eliot College, E3E room 8 Present: ajm4, tdb1 Absent: none +[tdb1: Documented by ajm4, comments added by tdb1.] + This meeting was between ajm4 and tdb1 to discuss and possibly implement parts of the CORE and FilterManager elements of the system. @@ -19,8 +21,12 @@ wants to use the file themseleves (ie, add comments). isn't seen to be a real problem though, as it was only going to be a "funky" extra ;-) +[tdb1: this will also solve security issues with + unauthorised third parties changing settings.] + + Next point was whether or not we would support elements -being able to be updated without restarting them ie, a host +being able to be updated without restarting them, ie. a host would be able to detect its configuration has changed and adjust accordingly. The method chosen was to use the last modified date stamp of the configuration file as an @@ -32,12 +38,14 @@ configuration ;-) ) ask the Configurator if its configuration has been updated, and act accordingly. The methods: - long Configuration.getLastModifed() and - boolean Configurator.isModified(config) + long Configuration.getLastModifed() and + boolean Configurator.isModified(String conf, long curTime) where thus implemented and the configurator test class modified to include a test of this system. +[tdb1: it was also noted at this stage that a java 'long' is + infact an IDL 'long long'.] The next item discussed was the CORBA IDL and general system @@ -67,33 +75,42 @@ to. When the FilterListener is contacted by a host it a HostInit object to handle this intialisation. The first thing a Host does is obtain its configuration, this is done by the HostInit object obtaining the configuration of the -host its behalf. An initial protocol of how this system +host on its behalf. An initial protocol of how this system works is as follows: +[tdb1: This is of course subject to alteration, but at the + time it seemed like a "good idea".] + Host FilterManager.HostInit STARTCONFIG -> - <- OK | ERROR + <- OK | ERROR LASTMODIFIED -> - <- LASTMODIFIED + <- LASTMODIFIED DO { PROPERTY -> - <- VALUE | ERROR + <- VALUE | ERROR } UNTIL GOT CONFIG ENDCONFIG -> - <- OK + <- OK If the property section returns an ERROR then this indicates to the host that that property requested doesn't exist, the Host will then deal with this either by ending with an error on the local system or by ignoring it if it can. +[tdb1: An ERROR after STARTCONFIG indicates no configuration + is available at all (ie. no file found).] + The above features where implemented. The next item needed to be developed is an architecture for FilterParent's and FilterChild's, as the next stage of Host -initialisation is to be past a reference to a FilterChild. +initialisation is to be passed a reference to a FilterChild. +[tdb1: "passed a reference" will mean a server and a port, + not to be confused with Java or CORBA references.] + It was noted that on a "heart beat" with the system, a Host should check to see if its configuration has changed. If it has it should then re-initialise itself. This will allow @@ -119,6 +136,11 @@ It was also noted that there is a need for coding stan As we had reached an appropriate stage to end, and given the late hour, it was decided to conclude the meeting. + +[tdb1: It was, afterall, nearly 7 hours coding !] + +[tdb1: As a post-meeting effort Makefile's were constructed + to allow easy compiling and configuration of code.] Meeting was concluded @ 20:45. Next meeting booked for 11:00 on Wednesday, until 12:30. Meeting with iau @ 13:30 on that