i-scream documentation viewer

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.