--- projects/cms/documentation/specification/spec-realtime.txt	2000/10/30 19:38:34	1.2
+++ projects/cms/documentation/specification/spec-realtime.txt	2000/10/31 16:12:25	1.4
@@ -9,12 +9,40 @@ System Component Startup
 
 CORE
 ----
+The core of the system provides little or no functionality
+to the operation of the system, but instead oversees the
+running.  At startup this should be the first component to
+intansiate.  It essentially acts as a central logging and 
+configuration distrubution site, the "central" in
+centralised monitoring system.  It may also be running the
+ORB or some components related to it.
 
+On startup the first thing it should do is read in any
+configuration files, start the logging interface then 
+prepare to bring the system online.  This is done by
+starting the various components.  If however the system
+configuration states that particular components are
+operating in "distributed" mode, then it blocks until
+the various key components have registered that they are 
+online.
 
 Client Interface
 ----------------
+The Client Interface is essentially just one component with 
+a series of lists within it. When run it should, obviously, 
+create an instance of the Client Interface, and then bind 
+this to the ORB and register with the naming service.
 
+It can then read its configuration in from the CORE and get
+a hook on the logging service that the CORE provides.
 
+It then needs to construct the "local clients". These 
+clients communicate with the system using the same interface
+as the external clients, but they are tailored to specific 
+purposes, such as E-Mail alerts, and SMS alerts. The Client 
+Interface then listens on a "well known" address for clients 
+to request a connection.
+
 Filter
 ------
 The filter is broken down into three main subcomponents. 
@@ -42,24 +70,56 @@ The filter is broken down into three main subcomponent
 At startup a Filter Manager object is activated at the "well 
 known" location (probably a given machine name at a 
 predefined port). The Filter Manager will create an instance 
-of the Main Filter, and any Filters under it's control. 
-Through some mechanism the other Filters, elsewhere on the 
-network, will register with the Filter Manager. The 
-Filter Manager will need to tell each Filter the location 
-of the Main Filter upon registering. The Filter Manager will 
-then be in a position to receive connections from hosts and 
-pass them off to Filters.
+of the Main Filter, and any Filters under it's control. It 
+should also bind itself to the ORB and register with the 
+naming service. 
 
+It can then read its configuration in from the CORE and get
+a hook on the logging service that the CORE provides.
+
+Through some mechanism the other Filters, elsewhere on the
+network, will register with the Filter Manager. The Filter
+Manager will need to tell each Filter the location of the
+Main Filter upon registering. The Filter Manager will then
+be in a position to receive connections from hosts and pass
+them off to Filters.
+
 System Running State
 ********************
 
 CORE
 ----
+Once the various components are running then the core is
+essentially idle, logging information and handling
+configuration changes.
 
-
 Client Interface
 ----------------
+In the running state the Client Interface is always 
+listening for clients on the "well known" address. When a 
+connection is received it is passed in to the main Client 
+Interface and the client is queried about which hosts it 
+wishes to receive information about. This is then stored in 
+an internal "routing table" so the Client Interface knows 
+which hosts to send the information on to. This routing 
+table is constructed with this form;
 
+  host1: client1 client2 client5
+  host2: client2
+  host3: client3 client4
+  host4: client1 client3
+
+This design is such that when a piece of information is 
+recieved from a host the Client Interface can immediately 
+see which clients wish to receive this data, without too 
+much searching.
+
+The "local clients" function just like any other client, 
+although they are local, in that they will wish to receive 
+information about hosts they are interested in. However, 
+they will contain a lot more logic, and be required to work 
+out who wants to be alerted about what, and when. They will 
+also be responsible for sending the alert.
 
 Filter
 ------