--- projects/cms/documentation/minutes/minutes-20001116.txt	2000/11/16 16:06:56	1.1
+++ projects/cms/documentation/minutes/minutes-20001116.txt	2000/11/16 18:35:30	1.2
@@ -1,26 +1,87 @@
-Minutes
+Minutes of meeting 16/11/00 @ 2pm
+Location: Eliot College E3E Room 8 and
+          UKC Computer Science Meeting Room
 
-0 - Fatal or Critical Errors    FATAL
-1 - All Errors                  ERROR
-2 - Warnings                    WARNING
-3 - System Component messages   SYSMSG
-4 - System Component init       SYSINIT
-5 - All debugging messages      DEBUG
+Present: ajm4, tdb1
+Absent: None
 
-Added Verbosity to logger.
-Create a Multi logger.
+Another sub-meeting where a few design decisions were made 
+regarding the core of the system, namely logging and 
+configuration.
 
-Configuration - system wide, defaults, etc.
+Firstly the idea of verbosity of logging messages was 
+finalised, and later implemented. The following levels are 
+currently supported my the write method of the logger, which 
+can be accessed as follows.
 
-Configuration structure will be...
+ Logger.write(String source, int verbosity, String message);
 
-system.conf
-hosts.conf
-clients.conf
-hosts/
-  host-hostname.domain.conf
-clients/
-  client-somename.conf (provisional)
+ 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
 
-1. host source = "host-mydnsname"
-2. config sys looks in hosts conf, then default, then null
\ No newline at end of file
+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.
\ No newline at end of file