documentation/minutes/minutes-20001116.txt

Minutes of meeting 16/11/00 @ 2pm
Location: Eliot College E3E Room 8 and
          UKC Computer Science Meeting Room

Present: ajm4, tdb1
Absent: None

Another sub-meeting where a few design decisions were made 
regarding the core of the system, namely logging and 
configuration.

Firstly the idea of verbosity of logging messages was 
finalised, and later implemented. The following levels are 
currently supported my the write method of the logger, which 
can be accessed as follows.

 Logger.write(String source, int verbosity, String message);

 Logger.FATAL   - (0) Fatal or Critical Errors
 Logger.ERROR   - (1) All Errors
 Logger.WARNING - (2) Warnings
 Logger.SYSMSG  - (3) System Component messages
 Logger.SYSINIT - (4) System Component initialisation
 Logger.DEBUG   - (5) All debugging messages

Although these are only integer values they should always be 
reference by their name on the left. This allows for easier 
reading of code, and greater expandability.

Next, still on the logging system, a need was found for a 
logger which allowed both logging to the screen and logging 
to a file, preferably with independant verbosity levels. It 
was decided that a multi-logger should be written that 
supported both features (using the existing classes).


The configuration system was also under review. There seems 
to be a need for default config files, grouping of configs, 
and hierarchical includes. These features will all be 
implemented allowing a greater degree of control over the 
system configuration, whilst retaining a simple and central 
point of management.

It was decided that the structure of the configuration would 
be as follows;

CONFROOT/
  system.conf
  hosts.conf
  clients.conf
  HOSTS/
    host-hostname.domain.conf
  CLIENTS/
    client-somename.conf

system.conf is a system wide configuration file (for the 
logger and so on), whilst the hosts.conf and clients.conf 
are default configurations for hosts and clients 
respectively. The HOSTS and CLIENTS subdirectories contain 
individual configuration files, and possibly group files. 
The filenames are not yet final.

The intended use of the system is that the configuration 
system, when asked for a property, would first look in an 
individual host (or client) configuration file. If it failed 
to find it there it would then try the default file, and 
finally failing that it would return null.

Includes would also fit into this structure, although it 
isn't entirely clear (to me at least) how this whole 
structure fits together, with overriding an so on. Circular 
includes have been thought of, and will be dealt with.


Finally, it was noted that there were still problems with 
the initial configuration of the system - ie. how to 
configure the configuration system. Various ideas were 
suggested including passing parameters on the commandline, 
or an initialisation configuration file.


The configuration plans above are to be considered and 
implemented by ajm4, hopefully by Monday. tdb1 will work on 
the logging side of the system.

Next full meeting is arranged for Monday, and the meeting 
room is booked from 10am-12pm and 2pm-5pm.
Revision:	1.2
Committed:	Thu Nov 16 18:35:30 2000 UTC (24 years ago) by tdb
Content type:	text/plain
Branch:	MAIN
Changes since 1.1:	+86 -25 lines
Log Message:	Finalised the minutes as far as I can. Hopefully ajm4 will clarify some of his ideas.
#	User	Rev	Content
1	tdb	1.2	Minutes of meeting 16/11/00 @ 2pm
2			Location: Eliot College E3E Room 8 and
3			UKC Computer Science Meeting Room
4
5			Present: ajm4, tdb1
6			Absent: None
7
8			Another sub-meeting where a few design decisions were made
9			regarding the core of the system, namely logging and
10			configuration.
11
12			Firstly the idea of verbosity of logging messages was
13			finalised, and later implemented. The following levels are
14			currently supported my the write method of the logger, which
15			can be accessed as follows.
16
17			Logger.write(String source, int verbosity, String message);
18
19			Logger.FATAL - (0) Fatal or Critical Errors
20			Logger.ERROR - (1) All Errors
21			Logger.WARNING - (2) Warnings
22			Logger.SYSMSG - (3) System Component messages
23			Logger.SYSINIT - (4) System Component initialisation
24			Logger.DEBUG - (5) All debugging messages
25
26			Although these are only integer values they should always be
27			reference by their name on the left. This allows for easier
28			reading of code, and greater expandability.
29
30			Next, still on the logging system, a need was found for a
31			logger which allowed both logging to the screen and logging
32			to a file, preferably with independant verbosity levels. It
33			was decided that a multi-logger should be written that
34			supported both features (using the existing classes).
35
36
37			The configuration system was also under review. There seems
38			to be a need for default config files, grouping of configs,
39			and hierarchical includes. These features will all be
40			implemented allowing a greater degree of control over the
41			system configuration, whilst retaining a simple and central
42			point of management.
43
44			It was decided that the structure of the configuration would
45			be as follows;
46
47			CONFROOT/
48			system.conf
49			hosts.conf
50			clients.conf
51			HOSTS/
52			host-hostname.domain.conf
53			CLIENTS/
54			client-somename.conf
55
56			system.conf is a system wide configuration file (for the
57			logger and so on), whilst the hosts.conf and clients.conf
58			are default configurations for hosts and clients
59			respectively. The HOSTS and CLIENTS subdirectories contain
60			individual configuration files, and possibly group files.
61			The filenames are not yet final.
62
63			The intended use of the system is that the configuration
64			system, when asked for a property, would first look in an
65			individual host (or client) configuration file. If it failed
66			to find it there it would then try the default file, and
67			finally failing that it would return null.
68
69			Includes would also fit into this structure, although it
70			isn't entirely clear (to me at least) how this whole
71			structure fits together, with overriding an so on. Circular
72			includes have been thought of, and will be dealt with.
73
74
75			Finally, it was noted that there were still problems with
76			the initial configuration of the system - ie. how to
77			configure the configuration system. Various ideas were
78			suggested including passing parameters on the commandline,
79			or an initialisation configuration file.
80
81
82			The configuration plans above are to be considered and
83			implemented by ajm4, hopefully by Monday. tdb1 will work on
84			the logging side of the system.
85	tdb	1.1
86	tdb	1.2	Next full meeting is arranged for Monday, and the meeting
87			room is booked from 10am-12pm and 2pm-5pm.