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, 11 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.
#	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.