documentation/minutes/minutes-20001113b.txt

Minutes of Meeting, 13/11/2000 @ 14:00
Location: Eliot College, E3E room 8

Present: ajm4, tdb1
Absent: none

This meeting was between ajm4 and tdb1 to discuss and
possibly implement parts of the CORE and FilterManager
elements of the system.


Initial discussion was on the configuration system of the
CORE which has been partially completed to date.  A key
decision that was made was that it will NOT be possible
for the elements of the system to update their own
configuration, as this will cause difficulties if the user
wants to use the file themseleves (ie, add comments).  This
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.]

A standard has almost be devised for filenames of 
configuration files. As it stands all hostname properties 
will be get in a file with the following name;

hostname.domain.properties

nb. This will always be *lower case*. This is important as 
    some hosts (eg. stuE...) have mixed case, so having all
    lower case saves confusion.

However, any other config files (such as the filterManager) 
can have any name in any case. The file itself will be of 
the name format;

name.properties

So in the case of the filterManager this would be 
"filterManager.properties".

A standard should be defined here for concistency.

Next point was whether or not we would support elements
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
indicator.  When a Configuration object is passed to an
element of the system it can determine when the loaded
configuration was last edited.  The element of the system
can then periodically (the period can be set in the
configuration ;-) ) ask the Configurator if its
configuration has been updated, and act accordingly.  The
methods: 

     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
package structure.  It was decided to use the ukc domain as
the root identifier for the project.  Packages therefore
follow the naming:

    uk.ac.ukc.iscream.<package>.<class>|<sub-package>
    
The IDL and currently implemented classes were updated to 
refelect this change.


The next item to be discussed was the initial thinking and
possible implementation of the FilterManager.  An initial
FilterManager class was fleshed out with hooks to the logger
and the configurator, it then creates a FilterListener class
which will listen for new Hosts trying to connect to the
system.  It was NOT decided how Hosts should find the system
however a method similar to the WPAD system used to locate
web caches was suggested by tdb1.

A Host contacts the FilterManager to initialise itself and
obtain a host and port number of a Filter that it will talk
to. When the FilterListener is contacted by a host it spawns
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 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
    LASTMODIFIED ->
                        <- LASTMODIFIED
    DO {
        PROPERTY ->
                        <- VALUE | ERROR
    } UNTIL GOT CONFIG
    
    ENDCONFIG ->
                        <- 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 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 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
has it should then re-initialise itself.  This will allow 
configuration changes to be made to any part of the system
knowing that on the next "heart beat" the configuration will
take effect.  A point to note about this is that if there is
an error in the configuration the Host will simply error and
die.  What we may want (but still undecided) is a constant
retry until the config is ok.  So the system administrator 
will see in the logger destination that there has been an
error in this new configuration and can make changes to 
rectify the problem, without having to interact with the 
Host program itself.


All code generated was placed in the "experimental" tree of
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.  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 
day.
Revision:	1.5
Committed:	Wed Nov 15 02:05:53 2000 UTC (24 years, 11 months 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.
#	Content
1	Minutes of Meeting, 13/11/2000 @ 14:00
2	Location: Eliot College, E3E room 8
3
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	[tdb1: this will also solve security issues with
23	unauthorised third parties changing settings.]
24
25	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
46	Next point was whether or not we would support elements
47	being able to be updated without restarting them, ie. a host
48	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	long Configuration.getLastModifed() and
60	boolean Configurator.isModified(String conf, long curTime)
61
62	where thus implemented and the configurator test class
63	modified to include a test of this system.
64
65	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
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	host on its behalf. An initial protocol of how this system
97	works is as follows (of course this is subject to later
98	alteration, but seemed like a "good idea at the time"):
99
100	Host FilterManager.HostInit
101	STARTCONFIG ->
102	<- OK \| ERROR
103	LASTMODIFIED ->
104	<- LASTMODIFIED
105	DO {
106	PROPERTY ->
107	<- VALUE \| ERROR
108	} UNTIL GOT CONFIG
109
110	ENDCONFIG ->
111	<- OK
112
113	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	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	The above features were implemented.
126
127
128
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	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
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	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
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	late hour, it was decided to conclude the meeting. It was,
163	after all, nearly 7 hours of coding ;-)
164
165	Since this meeting took place tdb1 has produced Makefiles
166	to allow easy compiling and configuration of the code.
167
168
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.