ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/projects/cms/documentation/minutes/minutes-20001113b.txt
Revision: 1.2
Committed: Wed Nov 15 00:19:49 2000 UTC (23 years, 11 months ago) by tdb
Content type: text/plain
Branch: MAIN
Changes since 1.1: +32 -10 lines
Log Message:
A few minor alterations, and comments.

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 tdb 1.2 [tdb1: Documented by ajm4, comments added by tdb1.]
8    
9 ajm 1.1 This meeting was between ajm4 and tdb1 to discuss and
10     possibly implement parts of the CORE and FilterManager
11     elements of the system.
12    
13    
14    
15     Initial discussion was on the configuration system of the
16     CORE which has been partially completed to date. A key
17     decision that was made was that it will NOT be possible
18     for the elements of the system to update their own
19     configuration, as this will cause difficulties if the user
20     wants to use the file themseleves (ie, add comments). This
21     isn't seen to be a real problem though, as it was only going
22     to be a "funky" extra ;-)
23    
24 tdb 1.2 [tdb1: this will also solve security issues with
25     unauthorised third parties changing settings.]
26    
27    
28 ajm 1.1 Next point was whether or not we would support elements
29 tdb 1.2 being able to be updated without restarting them, ie. a host
30 ajm 1.1 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
33     indicator. When a Configuration object is passed to an
34     element of the system it can determine when the loaded
35     configuration was last edited. The element of the system
36     can then periodically (the period can be set in the
37     configuration ;-) ) ask the Configurator if its
38     configuration has been updated, and act accordingly. The
39     methods:
40    
41 tdb 1.2 long Configuration.getLastModifed() and
42     boolean Configurator.isModified(String conf, long curTime)
43 ajm 1.1
44     where thus implemented and the configurator test class
45     modified to include a test of this system.
46    
47 tdb 1.2 [tdb1: it was also noted at this stage that a java 'long' is
48     infact an IDL 'long long'.]
49 ajm 1.1
50    
51     The next item discussed was the CORBA IDL and general system
52     package structure. It was decided to use the ukc domain as
53     the root identifier for the project. Packages therefore
54     follow the naming:
55    
56     uk.ac.ukc.iscream.<package>.<class>|<sub-package>
57    
58     The IDL and currently implemented classes were updated to
59     refelect this change.
60    
61    
62    
63     The next item to be discussed was the initial thinking and
64     possible implementation of the FilterManager. An initial
65     FilterManager class was fleshed out with hooks to the logger
66     and the configurator, it then creates a FilterListener class
67     which will listen for new Hosts trying to connect to the
68     system. It was NOT decided how Hosts should find the system
69     however a method similar to the WPAD system used to locate
70     web caches was suggested by tdb1.
71    
72     A Host contacts the FilterManager to initialise itself and
73     obtain a host and port number of a Filter that it will talk
74     to. When the FilterListener is contacted by a host it spawns
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 tdb 1.2 host on its behalf. An initial protocol of how this system
79 ajm 1.1 works is as follows:
80    
81 tdb 1.2 [tdb1: This is of course subject to alteration, but at the
82     time it seemed like a "good idea".]
83    
84 ajm 1.1 Host FilterManager.HostInit
85     STARTCONFIG ->
86 tdb 1.2 <- OK | ERROR
87 ajm 1.1 LASTMODIFIED ->
88 tdb 1.2 <- LASTMODIFIED
89 ajm 1.1 DO {
90     PROPERTY ->
91 tdb 1.2 <- VALUE | ERROR
92 ajm 1.1 } UNTIL GOT CONFIG
93    
94     ENDCONFIG ->
95 tdb 1.2 <- OK
96 ajm 1.1
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 tdb 1.2 [tdb1: An ERROR after STARTCONFIG indicates no configuration
103     is available at all (ie. no file found).]
104    
105 ajm 1.1 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 tdb 1.2 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 ajm 1.1
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
117     configuration changes to be made to any part of the system
118     knowing that on the next "heart beat" the configuration will
119     take effect. A point to note about this is that if there is
120     an error in the configuration the Host will simply error and
121     die. What we may want (but still undecided) is a constant
122     retry until the config is ok. So the system administrator
123     will see in the logger destination that there has been an
124     error in this new configuration and can make changes to
125     rectify the problem, without having to interact with the
126     Host program itself.
127    
128    
129    
130     All code generated was placed in the "experimental" tree of
131     CVS, awaiting approval from other group members.
132    
133     Many small bug fixes were made to the existing code.
134    
135     It was also noted that there is a need for coding standards.
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 tdb 1.2
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 ajm 1.1
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
147     day.