--- 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:33:45	1.3
@@ -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.
 
+It should also be noted at this stage that a java 'long' is 
+defined as a 'long long' in the IDL->Java mapping.
 
 
 The next item discussed was the CORBA IDL and general system
@@ -67,32 +75,44 @@ 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
-works is as follows:
+host on its behalf.  An initial protocol of how this system
+works is as follows (of course this is subject to later
+alteration, but seemed like a "good idea at the time"):
 
 Host                    FilterManager.HostInit
     STARTCONFIG ->
-            <- OK | ERROR
+                        <- OK | ERROR
     LASTMODIFIED ->
-            <- LASTMODIFIED
+                        <- LASTMODIFIED
     DO {
         PROPERTY ->
-            <- VALUE | ERROR
+                        <- VALUE | ERROR
     } UNTIL GOT CONFIG
     
     ENDCONFIG ->
-            <- OK
+                        <- OK
 
+If there is an ERROR returned after STARTCONFIG, this
+indicates to the Host that there is no configuration 
+available for it at this time.  It may be possible to
+continue using default values, but this is up to the host
+configuration.  Again, this is not a certain feature and
+should be discussed with other members of the group.
+
 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.
 
-The above features where implemented.
+The above features were 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.  This 'reference' will be a server and a port
+and not a reference in the CORBA or Java way of thinking.
 
 It was noted that on a "heart beat" with the system, a Host
 should check to see if its configuration has changed.  If it
@@ -111,14 +131,22 @@ Host program itself.
 
 
 All code generated was placed in the "experimental" tree of
-CVS, awaiting approval from other group members.
+CVS, awaiting approval from other group members.  It should
+also be noted that although CVS records tdb1 as the 
+'checker inner', it was infact ajm4...as he was the king of
+code during this meeting ;-p
 
 Many small bug fixes were made to the existing code.
 
 It was also noted that there is a need for coding standards.
 
 As we had reached an appropriate stage to end, and given the
-late hour, it was decided to conclude the meeting.
+late hour, it was decided to conclude the meeting.  It was,
+after all, nearly 7 hours of coding ;-)
+
+Since this meeting took place tdb1 has produced Makefiles
+to allow easy compiling and configuration of the code.
+
 
 Meeting was concluded @ 20:45. Next meeting booked for 11:00 
 on Wednesday, until 12:30. Meeting with iau @ 13:30 on that