i-scream documentation viewer

minutes-20001018.txt 

Minutes of Meeting, 18/10/2000 @ 2:00pm
Location: UKC Computer Science Meeting Room

Present: ab11, ajm4, pjm2, tdb1
Absent: none

This meeting was spent producing a features list for review 
by jc. This list can be found elsewhere. The idea behind 
this list was to summarise what the end product was going to 
be link, from our current plans, and to ensure that it met 
with the initial requirements of jc.

Also produced was a revised diagram of the system, taking 
into account the following alterations from the original 
diagram of 05/10/2000.

 - Web interface scrapped.
     It was decided that this was no longer required, since 
     any scripting language would connect directly to the 
     database to retrieve information.

 - Collector/Filter redefined.
     The collector/filter part of the server was redefined 
     such that a hierachy of them could be arranged to 
     spread the load of incoming data. Ultimately all data 
     goes through the last (and main) one, but it does at 
     least give an extra layer of organisation for the 
     administrator. ie. machines could be grouped (by 
     site?) and have their own collector/filter which 
     reports back to a central system - almost like a proxy.

 - DBI (DataBase Interface) added.
     This interface connects directly to the database, and 
     is therefore the only part of the system that need know 
     the exact workings of the database. It can also be 
     given funtionality to decide what information will be 
     stored in the database, and how it will be done.

 - Clients split to "real-time" and "historic"
     The clients are split into two groups. Firstly the 
     "real-time" clients (on the bottom left) connect 
     directly to the system via a client interface. This 
     allows the clients to receive up-to-date information 
     directly, rather than through the database. Secondly, 
     the "historic" clients connect to the database, either 
     directly or via an interface, and allow information 
     about the history of a machine to be viewed. Both of 
     these types of clients could actually be implemented in 
     one physical application, but the distinguishment has 
     been made at this level.
     It should also be noted that the "real-time" clients 
     have information pushed to them by the server, whilst 
     the "historic" clients pull information themselves.

This system can be seen in the following diagram;

    /documentation/minutes/system-20001018.gif

The meeting was concluded at 5pm.