Any client on the CFHT network must have open access to create, update, and retrieve information from the Status Server at any time.
In some cases, objects within the Status Server may have a short lifetime, so it must be possible to remove an object after it is no longer needed. If the Status Server is used as a staging area for building FITS headers, the FITS headers should probably be removed after the FITS file is created.
Once connected to the Status Server, any client must have the ability to add, update, retrieve, or remove information within the Status Server. This implies that there will not be any required permissions or membership to access control lists in order to view or modify data.
The Status Server must support the ability to store a variety of data types. At a minimum, the following data types must be supported.
In some cases, a client may be interested to know when the value of a particular object changes, but not interested in constantly polling the Status Server. As a result, it must be possible to place a monitor on objects. By placing a monitor on an object, the client will be informed when the object has changed state and what the new value of the object is.
In order to reduce the load on both Status Server and client, the client should be able to specify a "deadband" range for both floating point and integer objects. For example, given that the telescope pointing accuracy is around .1 arcseconds, it may make sense to provide a deadband limit surrounding the actual RA and Dec position of the telescope. As a result, monitors would not trigger for cases where a new value is not significantly different from a previous value.
The frequency with which a Status Server object is updated may exceed the desired notification frequency for a client monitoring the object. As a result, it must be possible for a client to specify a minimum time period between monitoring notifications. For example, if the datalogger information is stored in the Status Server, it would be updated every 10 seconds. However, a client monitoring a series of datalogger probes may only be interested in receiving an update each hour.
Some of the status information within the Status Server will have a limited useful lifetime beyond which the information should be considered expired or invalid. As an example, the seeing at the end of one evening should not be taken as the current seeing at the start of the next evening.
The valid lifetime of a status object must be the time frame within which clients would be notified of status updates of monitored objects.
Status Server objects must be grouped together in a tree-like fashion much like a file system. It would then be possible to traverse and manipulate objects within the Status Server much like traversing a directory tree in a file system. In such a system, it must be possible to access and refer to objects within the Status Server either via a fully qualified path-name combination or a relative path-name combination. This will require that the Status Server or API library keep track of the current directory for each client. An example of such a structure is shown in figure 1.
The Status Server should be designed to hold current information. However, it is likely that some information will need to be stored or archived for later use. It is quite possible that the monitoring capabilities of the Status Server will be sufficient for an archive client to compile a history. If not, the Status Server must be designed in a way so this support is available.
