This section covers the infrastructure required to enable users to manage the notification rules. It is very likely that some of the GUI windows and forms will be available after the core notification engine has been developed and tested.
The system must be open and accessible such that users can create, modify or remove notification rules. While the system will be provided by the software group, the management of the rules themselves will be a self managed process available to anyone within CFHT.
The software required to view and manage the rules must be available on both Windows and Unix platforms.
A modification of notification rules should not require a restart of the notification process. Instead, the notification engine should dynamically detect and apply rule changes on the fly.
When an alert condition is met, it must be available in a list of active alerts until the alert condition is no longer active. An example of how this could be done is to have a directory in the Status Server hold all alerts which are currently active. If the alert condition is no longer met, the alert will be removed from the directory. It would then be possible to monitor this directory and see the updates dynamically.
Once an alert condition has been triggered, it may not be easily apparent if the issue has been resolved remotely. For example, if a problem occurs it may cause a chain reaction of several notifications being triggered. As work is done to resolve issues, it would be useful to query the system and retrieve the current alert status. This query would ideally be available from a remote device. For example, if a specially coded email is sent to specific email address at CFHT, a process under that account could filter the request and send back an email with the contents of the active alert list.