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 by the write method of the logger, which 
can be accessed as follows.

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

The verbosity can be one of the following values,

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