ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/projects/cms/documentation/minutes/minutes-20001116.txt
(Generate patch)

Comparing projects/cms/documentation/minutes/minutes-20001116.txt (file contents):
Revision 1.1 by tdb, Thu Nov 16 16:06:56 2000 UTC vs.
Revision 1.3 by tdb, Fri Nov 17 16:22:39 2000 UTC

# Line 1 | Line 1
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.

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines