ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/projects/cms/documentation/minutes/minutes-20001116.txt
Revision: 1.3
Committed: Fri Nov 17 16:22:39 2000 UTC (23 years, 4 months ago) by tdb
Content type: text/plain
Branch: MAIN
CVS Tags: PROJECT_COMPLETION, HEAD
Changes since 1.2: +3 -1 lines
Log Message:
Typo correction.

File Contents

# Content
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.