| 1 |
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 by 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 |
The verbosity can be one of the following values, |
| 20 |
|
| 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. |
