ViewVC Help

View File | Revision Log | Show Annotations | Revision Graph | Root Listing

root/i-scream/projects/cms/documentation/minutes/minutes-20001113b.txt

Comparing projects/cms/documentation/minutes/minutes-20001113b.txt (file contents):
Revision 1.1 by ajm, Wed Nov 15 00:01:05 2000 UTC vs.
Revision 1.5 by tdb, Wed Nov 15 02:05:53 2000 UTC

#	Line 1 | Line 1
1		Minutes of Meeting, 13/11/2000 @ 14:00
2	<	Location: Eliot College, room E3E
2	>	Location: Eliot College, E3E room 8
3
4		Present: ajm4, tdb1
5		Absent: none
#	Line 19 | Line 19 | wants to use the file themseleves (ie, add comments).
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
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
#	Line 32 | Line 56 | 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(config)
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
#	Line 67 | Line 93 | to. When the FilterListener is contacted by a host it
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 its behalf.  An initial protocol of how this system
97	<	works is as follows:
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
102	>	<- OK | ERROR
103		LASTMODIFIED ->
104	<	<- LASTMODIFIED
104	>	<- LASTMODIFIED
105		DO {
106		PROPERTY ->
107	<	<- VALUE | ERROR
107	>	<- VALUE | ERROR
108		} UNTIL GOT CONFIG
109
110		ENDCONFIG ->
111	<	<- OK
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 where implemented.
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 past a reference to a FilterChild.
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
#	Line 111 | Line 149 | Host program itself.
149
150
151		All code generated was placed in the "experimental" tree of
152	<	CVS, awaiting approval from other group members.
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.
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

Diff Legend

–	Removed lines
+	Added lines
<	Changed lines
>	Changed lines