ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/projects/cms/documentation/minutes/minutes-20001129b.txt
Revision: 1.1
Committed: Thu Nov 30 23:56:06 2000 UTC (23 years, 4 months ago) by tdb
Content type: text/plain
Branch: MAIN
CVS Tags: PROJECT_COMPLETION, HEAD
Log Message:
Minutes from sub-meeting on 29/11/2000.

File Contents

# Content
1 Minutes of meeting 29/11/00 @ 5pm
2 Location: UKC Computer Science Multimedia Lab then
3 Eliot College computer room.
4
5 Present: ajm4, tdb1
6 Absent: None
7
8 AJ and Tim met to discuss and work on the code tidying
9 issues. It was decided, afterwards, that the work should be
10 documented in the form of minutes, so that a record can be
11 made of what's happened.
12
13 Meeting start (MM Lab): 17:00
14 Break for dinner: 22:00
15 Resume (Eliot) : 22:30
16 Finish : 04:30
17
18
19 Firstly a new class was introduced to the system. This
20 class, called the ReferenceManager, was originally designed
21 to hold references to the various items that a system
22 component (ie. the filter) would require. This would cut
23 down on passing of references between classes.
24
25 However, as the was implemented it became clear that it
26 could infact handle the CORBA references as well, and then,
27 further to that, all the CORBA initialisation. In the end it
28 ended up handling all the CORBA code, and held references to
29 all the things required by a system component.
30
31 The class was designed as a singleton, again to cut down on
32 reference passing. Generally the class needs to be
33 initialised before use, and this will be done in the main
34 method of the component it's involved in. From then on a
35 reference can be obtained by any class within the component
36 using one simple method call.
37
38 This has significantly reduced the complexity of the main
39 methods of the system components, and allowed a clear line
40 to be drawn between the CORBA code and the rest of the code.
41 This has also meant that all the CORBA error handling is
42 focused in one place, and can therefore be more thoroughly
43 dealt with.
44
45
46 The next item to be dealt with was the packaging. This was a
47 major, but required, task and took some organising. The
48 whole system now resides below the following package,
49
50 uk.ac.ukc.iscream;
51
52 The currently list of subpackages are,
53
54 uk.ac.ukc.iscream.core;
55 uk.ac.ukc.iscream.core.loggers;
56 uk.ac.ukc.iscream.filter;
57 uk.ac.ukc.iscream.filtermanager;
58 uk.ac.ukc.iscream.rootfilter;
59 uk.ac.ukc.iscream.util;
60
61 The first five containing the existing components, but the
62 last has been created to house more general purpose classes.
63 Currently it has the xml parsing classes, and the
64 ReferenceManager. It will, in the future, hold a class to
65 deal with naming and generation of toString()'s.
66
67 The inclusion of these packages has made the directory
68 structure look a bit unwieldy, but as you'll see further
69 down makefile's have been written to make compilation
70 easier.
71
72 As a side note, the generated IDL classes reside in similar
73 packages, although they are in a separate location to avoid
74 confusion. Ultimately they will be merged.
75
76
77 Makefile's have been generated for the whole system. They
78 allow easy compilation of any component, or the whole thing.
79 They also allow for easy cleaning of compiled class files.
80 It is expected that they will in future support packaging of
81 the system into JAR files.
82
83 They work on a recursive structure, with a single root
84 Makefile. Each directory contains it's own Makefile for the
85 files it contains, with links to any subdirectories that
86 also contain Makefiles. This makes the system much more
87 manageable when adding, changing, and removing class files.
88 Ultimately only the root Makefile need be used, and it will
89 recursively execute all the others.
90
91
92 As a result of the above packaging, and the ReferenceManager
93 it became necessary to tidy large chunks of code. The main
94 two done were the Filter and RootFilter. Both now make use
95 of the ReferenceManager throughout, and have a nice common
96 theme through them - similar variable names, and class
97 structure. These classes are now much nearer the required
98 standards.
99
100 Also modified were the loggers in the core. They now reside
101 in a seperate subdirectory of the core, although this could
102 be moved. This layer of seperation makes life much easier
103 for managing and adding loggers.
104
105
106 That was about it for changes. A few bugs were fixed as
107 things progressed, but the functionality of the system (from
108 an external point of view) remained pretty much the same
109 throughout.
110
111 A short list of "nice features" to be added was prepared.
112 This list is in no certain order, and there is no gaurantee
113 they'll even be done in the near future.
114
115 - redesign the toString() methods. Modifying them, at
116 present requires changing every class. This is bad. A
117 new class in the util package could be created to
118 centralise this behaviour.
119 The toString() method is mainly used for logging
120 purposes.
121
122 - implement "remote logging" sessions. This would require
123 modifying the exist setup, but the majority of code is
124 in place to support it already. The idea of remote
125 logging is that a logging console could be fired up
126 independently on the server, and allow the user to
127 monitor the status of the system.
128
129 - improve error handling, and exception catching. Fatal
130 errors should be informative to the end user.
131
132 - the SimpleSwingLogger is broken. It will, after quite a
133 few thousand lines, run out of memory and crash. This
134 bug was identified previously, but the cause only found
135 during the course of this meet.
136
137 - allow hosts (and clients?) to log to the central logger
138 as well. This would require a "logger proxy" of sorts,
139 but it is suggested that this could be encapsulated in
140 the existing UDP packages - ie. generate a packet of
141 type "logmsg" that the UDP reading class will direct
142 straight into the system logger.
143
144 - sort of garbage collection issues, specifically with the
145 Configuration objects, although there may be other areas
146 that have yet to be found.
147
148 - the configuration system support dynamic updates, and
149 the host makes good use of this feature. However, it
150 would be nice if the server could implement this
151 internally where possible.
152
153
154 The semi-meeting was concluded at a rather late (or early)
155 hour after some very productive work.