ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/projects/cms/documentation/minutes/minutes-20001113b.txt
Revision: 1.5
Committed: Wed Nov 15 02:05:53 2000 UTC (24 years ago) by tdb
Content type: text/plain
Branch: MAIN
CVS Tags: PROJECT_COMPLETION, HEAD
Changes since 1.4: +20 -0 lines
Log Message: 
Added a quick bit about configuration file names.

File Contents

# User Rev Content
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     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 tdb 1.2 [tdb1: this will also solve security issues with
23     unauthorised third parties changing settings.]
24    
25 tdb 1.5 A standard has almost be devised for filenames of
26     configuration files. As it stands all hostname properties
27     will be get in a file with the following name;
28    
29     hostname.domain.properties
30    
31     nb. This will always be *lower case*. This is important as
32     some hosts (eg. stuE...) have mixed case, so having all
33     lower case saves confusion.
34    
35     However, any other config files (such as the filterManager)
36     can have any name in any case. The file itself will be of
37     the name format;
38    
39     name.properties
40    
41     So in the case of the filterManager this would be
42     "filterManager.properties".
43    
44     A standard should be defined here for concistency.
45 tdb 1.2
46 ajm 1.1 Next point was whether or not we would support elements
47 tdb 1.2 being able to be updated without restarting them, ie. a host
48 ajm 1.1 would be able to detect its configuration has changed and
49     adjust accordingly. The method chosen was to use the last
50     modified date stamp of the configuration file as an
51     indicator. When a Configuration object is passed to an
52     element of the system it can determine when the loaded
53     configuration was last edited. The element of the system
54     can then periodically (the period can be set in the
55     configuration ;-) ) ask the Configurator if its
56     configuration has been updated, and act accordingly. The
57     methods:
58    
59 tdb 1.2 long Configuration.getLastModifed() and
60     boolean Configurator.isModified(String conf, long curTime)
61 ajm 1.1
62     where thus implemented and the configurator test class
63     modified to include a test of this system.
64    
65 ajm 1.3 It should also be noted at this stage that a java 'long' is
66     defined as a 'long long' in the IDL->Java mapping.
67 ajm 1.1
68    
69     The next item discussed was the CORBA IDL and general system
70     package structure. It was decided to use the ukc domain as
71     the root identifier for the project. Packages therefore
72     follow the naming:
73    
74     uk.ac.ukc.iscream.<package>.<class>|<sub-package>
75    
76     The IDL and currently implemented classes were updated to
77     refelect this change.
78    
79    
80    
81     The next item to be discussed was the initial thinking and
82     possible implementation of the FilterManager. An initial
83     FilterManager class was fleshed out with hooks to the logger
84     and the configurator, it then creates a FilterListener class
85     which will listen for new Hosts trying to connect to the
86     system. It was NOT decided how Hosts should find the system
87     however a method similar to the WPAD system used to locate
88     web caches was suggested by tdb1.
89    
90     A Host contacts the FilterManager to initialise itself and
91     obtain a host and port number of a Filter that it will talk
92     to. When the FilterListener is contacted by a host it spawns
93     a HostInit object to handle this intialisation. The first
94     thing a Host does is obtain its configuration, this is done
95     by the HostInit object obtaining the configuration of the
96 tdb 1.2 host on its behalf. An initial protocol of how this system
97 ajm 1.3 works is as follows (of course this is subject to later
98     alteration, but seemed like a "good idea at the time"):
99 tdb 1.2
100 ajm 1.1 Host FilterManager.HostInit
101     STARTCONFIG ->
102 tdb 1.2 <- OK | ERROR
103 ajm 1.1 LASTMODIFIED ->
104 tdb 1.2 <- LASTMODIFIED
105 ajm 1.1 DO {
106     PROPERTY ->
107 tdb 1.2 <- VALUE | ERROR
108 ajm 1.1 } UNTIL GOT CONFIG
109    
110     ENDCONFIG ->
111 tdb 1.2 <- OK
112 ajm 1.1
113 ajm 1.3 If there is an ERROR returned after STARTCONFIG, this
114     indicates to the Host that there is no configuration
115     available for it at this time. It may be possible to
116     continue using default values, but this is up to the host
117     configuration. Again, this is not a certain feature and
118     should be discussed with other members of the group.
119    
120 ajm 1.1 If the property section returns an ERROR then this indicates
121     to the host that that property requested doesn't exist, the
122     Host will then deal with this either by ending with an error
123     on the local system or by ignoring it if it can.
124    
125 ajm 1.3 The above features were implemented.
126    
127 tdb 1.2
128 ajm 1.1
129     The next item needed to be developed is an architecture for
130     FilterParent's and FilterChild's, as the next stage of Host
131 ajm 1.3 initialisation is to be passed a 'reference' to a
132     FilterChild. This 'reference' will be a server and a port
133     and not a reference in the CORBA or Java way of thinking.
134 ajm 1.1
135     It was noted that on a "heart beat" with the system, a Host
136     should check to see if its configuration has changed. If it
137     has it should then re-initialise itself. This will allow
138     configuration changes to be made to any part of the system
139     knowing that on the next "heart beat" the configuration will
140     take effect. A point to note about this is that if there is
141     an error in the configuration the Host will simply error and
142     die. What we may want (but still undecided) is a constant
143     retry until the config is ok. So the system administrator
144     will see in the logger destination that there has been an
145     error in this new configuration and can make changes to
146     rectify the problem, without having to interact with the
147     Host program itself.
148    
149    
150    
151     All code generated was placed in the "experimental" tree of
152 ajm 1.3 CVS, awaiting approval from other group members. It should
153     also be noted that although CVS records tdb1 as the
154     'checker inner', it was infact ajm4...as he was the king of
155     code during this meeting ;-p
156 ajm 1.1
157     Many small bug fixes were made to the existing code.
158    
159     It was also noted that there is a need for coding standards.
160    
161     As we had reached an appropriate stage to end, and given the
162 ajm 1.3 late hour, it was decided to conclude the meeting. It was,
163     after all, nearly 7 hours of coding ;-)
164 tdb 1.2
165 ajm 1.3 Since this meeting took place tdb1 has produced Makefiles
166     to allow easy compiling and configuration of the code.
167 tdb 1.2
168 ajm 1.1
169     Meeting was concluded @ 20:45. Next meeting booked for 11:00
170     on Wednesday, until 12:30. Meeting with iau @ 13:30 on that
171     day.