i-scream documentation viewer
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.
