ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/projects/cms/documentation/minutes/minutes-20001113b.txt
(Generate patch)

Comparing projects/cms/documentation/minutes/minutes-20001113b.txt (file contents):
Revision 1.1 by ajm, Wed Nov 15 00:01:05 2000 UTC vs.
Revision 1.2 by tdb, Wed Nov 15 00:19:49 2000 UTC

# Line 1 | Line 1
1   Minutes of Meeting, 13/11/2000 @ 14:00
2 < Location: Eliot College, room E3E
2 > Location: Eliot College, E3E room 8
3  
4   Present: ajm4, tdb1
5   Absent: none
6  
7 + [tdb1: Documented by ajm4, comments added by tdb1.]
8 +
9   This meeting was between ajm4 and tdb1 to discuss and
10   possibly implement parts of the CORE and FilterManager
11   elements of the system.
# Line 19 | Line 21 | wants to use the file themseleves (ie, add comments).
21   isn't seen to be a real problem though, as it was only going
22   to be a "funky" extra ;-)
23  
24 + [tdb1: this will also solve security issues with
25 +       unauthorised third parties changing settings.]
26 +
27 +
28   Next point was whether or not we would support elements
29 < being able to be updated without restarting them ie, a host
29 > being able to be updated without restarting them, ie. a host
30   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
# Line 32 | Line 38 | configuration ;-) ) ask the Configurator if its
38   configuration has been updated, and act accordingly.  The
39   methods:
40  
41 <       long Configuration.getLastModifed() and
42 <    boolean Configurator.isModified(config)
41 >     long Configuration.getLastModifed() and
42 >  boolean Configurator.isModified(String conf, long curTime)
43  
44   where thus implemented and the configurator test class
45   modified to include a test of this system.
46  
47 + [tdb1: it was also noted at this stage that a java 'long' is
48 +       infact an IDL 'long long'.]
49  
50  
51   The next item discussed was the CORBA IDL and general system
# Line 67 | Line 75 | to. When the FilterListener is contacted by a host it
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 < host its behalf.  An initial protocol of how this system
78 > host on its behalf.  An initial protocol of how this system
79   works is as follows:
80  
81 + [tdb1: This is of course subject to alteration, but at the
82 +       time it seemed like a "good idea".]
83 +
84   Host                    FilterManager.HostInit
85      STARTCONFIG ->
86 <            <- OK | ERROR
86 >                        <- OK | ERROR
87      LASTMODIFIED ->
88 <            <- LASTMODIFIED
88 >                        <- LASTMODIFIED
89      DO {
90          PROPERTY ->
91 <            <- VALUE | ERROR
91 >                        <- VALUE | ERROR
92      } UNTIL GOT CONFIG
93      
94      ENDCONFIG ->
95 <            <- OK
95 >                        <- OK
96  
97   If the property section returns an ERROR then this indicates
98   to the host that that property requested doesn't exist, the
99   Host will then deal with this either by ending with an error
100   on the local system or by ignoring it if it can.
101  
102 + [tdb1: An ERROR after STARTCONFIG indicates no configuration
103 +       is available at all (ie. no file found).]
104 +
105   The above features where implemented.
106  
107   The next item needed to be developed is an architecture for
108   FilterParent's and FilterChild's, as the next stage of Host
109 < initialisation is to be past a reference to a FilterChild.
109 > initialisation is to be passed a reference to a FilterChild.
110  
111 + [tdb1: "passed a reference" will mean a server and a port,
112 +       not to be confused with Java or CORBA references.]
113 +
114   It was noted that on a "heart beat" with the system, a Host
115   should check to see if its configuration has changed.  If it
116   has it should then re-initialise itself.  This will allow
# Line 119 | Line 136 | It was also noted that there is a need for coding stan
136  
137   As we had reached an appropriate stage to end, and given the
138   late hour, it was decided to conclude the meeting.
139 +
140 + [tdb1: It was, afterall, nearly 7 hours coding !]
141 +
142 + [tdb1: As a post-meeting effort Makefile's were constructed
143 +       to allow easy compiling and configuration of code.]
144  
145   Meeting was concluded @ 20:45. Next meeting booked for 11:00
146   on Wednesday, until 12:30. Meeting with iau @ 13:30 on that

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines