documentation/minutes/minutes-20001113b.txt

Minutes of Meeting, 13/11/2000 @ 14:00
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.


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.]


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.

[tdb1: it was also noted at this stage that a java 'long' is 
       infact an IDL 'long long'.]


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:

[tdb1: This is of course subject to alteration, but at the 
       time it seemed like a "good idea".]

Host                    FilterManager.HostInit
    STARTCONFIG ->
                        <- OK | ERROR
    LASTMODIFIED ->
                        <- LASTMODIFIED
    DO {
        PROPERTY ->
                        <- VALUE | ERROR
    } UNTIL GOT CONFIG
    
    ENDCONFIG ->
                        <- OK

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.

[tdb1: An ERROR after STARTCONFIG indicates no configuration 
       is available at all (ie. no file found).]

The above features where 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.

[tdb1: "passed a reference" will mean a server and a port, 
       not to be confused with Java or CORBA references.]

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.

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.

[tdb1: It was, afterall, nearly 7 hours coding !]

[tdb1: As a post-meeting effort Makefile's were constructed 
       to allow easy compiling and configuration of 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.2
Committed:	Wed Nov 15 00:19:49 2000 UTC (23 years, 5 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.
#	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	[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.
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	[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
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
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	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
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	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
87	LASTMODIFIED ->
88	<- LASTMODIFIED
89	DO {
90	PROPERTY ->
91	<- VALUE \| ERROR
92	} UNTIL GOT CONFIG
93
94	ENDCONFIG ->
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 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
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
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
147	day.