documentation/minutes/minutes-20001113b.txt

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

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 ;-)

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(config)

where thus implemented and the configurator test class
modified to include a test of this system.


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 its behalf.  An initial protocol of how this system
works is as follows:

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.

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 past a reference to a FilterChild.

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.

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.1
Committed:	Wed Nov 15 00:01:05 2000 UTC (23 years, 5 months ago) by ajm
Content type:	text/plain
Branch:	MAIN
Log Message:	initial check in
#	User	Rev	Content
1	ajm	1.1	Minutes of Meeting, 13/11/2000 @ 14:00
2			Location: Eliot College, room E3E
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			Next point was whether or not we would support elements
23			being able to be updated without restarting them ie, a host
24			would be able to detect its configuration has changed and
25			adjust accordingly. The method chosen was to use the last
26			modified date stamp of the configuration file as an
27			indicator. When a Configuration object is passed to an
28			element of the system it can determine when the loaded
29			configuration was last edited. The element of the system
30			can then periodically (the period can be set in the
31			configuration ;-) ) ask the Configurator if its
32			configuration has been updated, and act accordingly. The
33			methods:
34
35			long Configuration.getLastModifed() and
36			boolean Configurator.isModified(config)
37
38			where thus implemented and the configurator test class
39			modified to include a test of this system.
40
41
42
43			The next item discussed was the CORBA IDL and general system
44			package structure. It was decided to use the ukc domain as
45			the root identifier for the project. Packages therefore
46			follow the naming:
47
48			uk.ac.ukc.iscream.<package>.<class>\|<sub-package>
49
50			The IDL and currently implemented classes were updated to
51			refelect this change.
52
53
54
55			The next item to be discussed was the initial thinking and
56			possible implementation of the FilterManager. An initial
57			FilterManager class was fleshed out with hooks to the logger
58			and the configurator, it then creates a FilterListener class
59			which will listen for new Hosts trying to connect to the
60			system. It was NOT decided how Hosts should find the system
61			however a method similar to the WPAD system used to locate
62			web caches was suggested by tdb1.
63
64			A Host contacts the FilterManager to initialise itself and
65			obtain a host and port number of a Filter that it will talk
66			to. When the FilterListener is contacted by a host it spawns
67			a HostInit object to handle this intialisation. The first
68			thing a Host does is obtain its configuration, this is done
69			by the HostInit object obtaining the configuration of the
70			host its behalf. An initial protocol of how this system
71			works is as follows:
72
73			Host FilterManager.HostInit
74			STARTCONFIG ->
75			<- OK \| ERROR
76			LASTMODIFIED ->
77			<- LASTMODIFIED
78			DO {
79			PROPERTY ->
80			<- VALUE \| ERROR
81			} UNTIL GOT CONFIG
82
83			ENDCONFIG ->
84			<- OK
85
86			If the property section returns an ERROR then this indicates
87			to the host that that property requested doesn't exist, the
88			Host will then deal with this either by ending with an error
89			on the local system or by ignoring it if it can.
90
91			The above features where implemented.
92
93			The next item needed to be developed is an architecture for
94			FilterParent's and FilterChild's, as the next stage of Host
95			initialisation is to be past a reference to a FilterChild.
96
97			It was noted that on a "heart beat" with the system, a Host
98			should check to see if its configuration has changed. If it
99			has it should then re-initialise itself. This will allow
100			configuration changes to be made to any part of the system
101			knowing that on the next "heart beat" the configuration will
102			take effect. A point to note about this is that if there is
103			an error in the configuration the Host will simply error and
104			die. What we may want (but still undecided) is a constant
105			retry until the config is ok. So the system administrator
106			will see in the logger destination that there has been an
107			error in this new configuration and can make changes to
108			rectify the problem, without having to interact with the
109			Host program itself.
110
111
112
113			All code generated was placed in the "experimental" tree of
114			CVS, awaiting approval from other group members.
115
116			Many small bug fixes were made to the existing code.
117
118			It was also noted that there is a need for coding standards.
119
120			As we had reached an appropriate stage to end, and given the
121			late hour, it was decided to conclude the meeting.
122
123			Meeting was concluded @ 20:45. Next meeting booked for 11:00
124			on Wednesday, until 12:30. Meeting with iau @ 13:30 on that
125			day.