documentation/minutes/minutes-20001129b.txt

Minutes of meeting 29/11/00 @ 5pm
Location: UKC Computer Science Multimedia Lab then
          Eliot College computer room.

Present: ajm4, tdb1
Absent: None

AJ and Tim met to discuss and work on the code tidying 
issues. It was decided, afterwards, that the work should be 
documented in the form of minutes, so that a record can be 
made of what's happened.

Meeting start (MM Lab): 17:00
Break for dinner: 22:00
Resume (Eliot) : 22:30 
Finish : 04:30


Firstly a new class was introduced to the system. This 
class, called the ReferenceManager, was originally designed 
to hold references to the various items that a system 
component (ie. the filter) would require. This would cut 
down on passing of references between classes.

However, as the was implemented it became clear that it 
could infact handle the CORBA references as well, and then, 
further to that, all the CORBA initialisation. In the end it 
ended up handling all the CORBA code, and held references to 
all the things required by a system component.

The class was designed as a singleton, again to cut down on 
reference passing. Generally the class needs to be 
initialised before use, and this will be done in the main 
method of the component it's involved in. From then on a 
reference can be obtained by any class within the component 
using one simple method call.

This has significantly reduced the complexity of the main 
methods of the system components, and allowed a clear line 
to be drawn between the CORBA code and the rest of the code. 
This has also meant that all the CORBA error handling is 
focused in one place, and can therefore be more thoroughly 
dealt with.


The next item to be dealt with was the packaging. This was a 
major, but required, task and took some organising. The 
whole system now resides below the following package,

  uk.ac.ukc.iscream;

The currently list of subpackages are,

  uk.ac.ukc.iscream.core;
  uk.ac.ukc.iscream.core.loggers;
  uk.ac.ukc.iscream.filter;
  uk.ac.ukc.iscream.filtermanager;
  uk.ac.ukc.iscream.rootfilter;
  uk.ac.ukc.iscream.util;

The first five containing the existing components, but the 
last has been created to house more general purpose classes. 
Currently it has the xml parsing classes, and the 
ReferenceManager. It will, in the future, hold a class to 
deal with naming and generation of toString()'s.

The inclusion of these packages has made the directory 
structure look a bit unwieldy, but as you'll see further 
down makefile's have been written to make compilation 
easier.

As a side note, the generated IDL classes reside in similar 
packages, although they are in a separate location to avoid 
confusion. Ultimately they will be merged.


Makefile's have been generated for the whole system. They 
allow easy compilation of any component, or the whole thing. 
They also allow for easy cleaning of compiled class files. 
It is expected that they will in future support packaging of 
the system into JAR files.

They work on a recursive structure, with a single root 
Makefile. Each directory contains it's own Makefile for the 
files it contains, with links to any subdirectories that 
also contain Makefiles. This makes the system much more 
manageable when adding, changing, and removing class files. 
Ultimately only the root Makefile need be used, and it will 
recursively execute all the others.


As a result of the above packaging, and the ReferenceManager 
it became necessary to tidy large chunks of code. The main 
two done were the Filter and RootFilter. Both now make use 
of the ReferenceManager throughout, and have a nice common 
theme through them - similar variable names, and class 
structure. These classes are now much nearer the required 
standards.

Also modified were the loggers in the core. They now reside 
in a seperate subdirectory of the core, although this could 
be moved. This layer of seperation makes life much easier 
for managing and adding loggers.


That was about it for changes. A few bugs were fixed as 
things progressed, but the functionality of the system (from 
an external point of view) remained pretty much the same 
throughout.

A short list of "nice features" to be added was prepared. 
This list is in no certain order, and there is no gaurantee 
they'll even be done in the near future.

  - redesign the toString() methods. Modifying them, at 
    present requires changing every class. This is bad. A 
    new class in the util package could be created to 
    centralise this behaviour.
    The toString() method is mainly used for logging 
    purposes.
  
  - implement "remote logging" sessions. This would require 
    modifying the exist setup, but the majority of code is 
    in place to support it already. The idea of remote 
    logging is that a logging console could be fired up 
    independently on the server, and allow the user to 
    monitor the status of the system.
  
  - improve error handling, and exception catching. Fatal 
    errors should be informative to the end user.
  
  - the SimpleSwingLogger is broken. It will, after quite a 
    few thousand lines, run out of memory and crash. This 
    bug was identified previously, but the cause only found 
    during the course of this meet.
  
  - allow hosts (and clients?) to log to the central logger 
    as well. This would require a "logger proxy" of sorts, 
    but it is suggested that this could be encapsulated in 
    the existing UDP packages - ie. generate a packet of 
    type "logmsg" that the UDP reading class will direct 
    straight into the system logger.
  
  - sort of garbage collection issues, specifically with the 
    Configuration objects, although there may be other areas 
    that have yet to be found.
  
  - the configuration system support dynamic updates, and 
    the host makes good use of this feature. However, it 
    would be nice if the server could implement this 
    internally where possible.


The semi-meeting was concluded at a rather late (or early) 
hour after some very productive work.
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.
#	User	Rev	Content
1	tdb	1.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.