| 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 by 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 |
| 18 |
< |
hosts.conf |
| 19 |
< |
clients.conf |
| 20 |
< |
hosts/ |
| 21 |
< |
host-hostname.domain.conf |
| 22 |
< |
clients/ |
| 23 |
< |
client-somename.conf (provisional) |
| 19 |
> |
The verbosity can be one of the following values, |
| 20 |
|
|
| 21 |
< |
1. host source = "host-mydnsname" |
| 22 |
< |
2. config sys looks in hosts conf, then default, then null |
| 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 |
> |
|
| 88 |
> |
Next full meeting is arranged for Monday, and the meeting |
| 89 |
> |
room is booked from 10am-12pm and 2pm-5pm. |
