1 |
< |
Minutes |
1 |
> |
Minutes of meeting 16/11/00 @ 2pm |
2 |
> |
Location: Eliot College E3E Room 8 and |
3 |
> |
UKC Computer Science Meeting Room |
4 |
|
|
5 |
< |
0 - Fatal or Critical Errors FATAL |
6 |
< |
1 - All Errors ERROR |
5 |
< |
2 - Warnings WARNING |
6 |
< |
3 - System Component messages SYSMSG |
7 |
< |
4 - System Component init SYSINIT |
8 |
< |
5 - All debugging messages DEBUG |
5 |
> |
Present: ajm4, tdb1 |
6 |
> |
Absent: None |
7 |
|
|
8 |
< |
Added Verbosity to logger. |
9 |
< |
Create a Multi logger. |
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 |
< |
Configuration - system wide, defaults, etc. |
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 |
< |
Configuration structure will be... |
17 |
> |
Logger.write(String source, int verbosity, String message); |
18 |
|
|
19 |
< |
system.conf |
20 |
< |
hosts.conf |
21 |
< |
clients.conf |
22 |
< |
hosts/ |
23 |
< |
host-hostname.domain.conf |
24 |
< |
clients/ |
23 |
< |
client-somename.conf (provisional) |
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 |
< |
1. host source = "host-mydnsname" |
27 |
< |
2. config sys looks in hosts conf, then default, then null |
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 |
> |
|
86 |
> |
Next full meeting is arranged for Monday, and the meeting |
87 |
> |
room is booked from 10am-12pm and 2pm-5pm. |