Just practicing to pass the Turing test.
The News Server Model of OA&M
The following description is offered as a logical model for the purposes of discussion. It is a formalisation of the ideas first presented in the memo "OA&M for the NAP" to David Houseman from John Pucknell and David Bayly, dated Apr 8th 92.
Each component of a NAP oriented IIE posts events to a central OA&M process - the News Server. This server must maintain a list of client processes which declare an interest in a subset of the available events (interest profile). Client processes might have the responsibility for driving a graphic workstation, or displaying text messages on a character based terminal. Another class of client might be a process whose function is to track a time series of certain events and to generate an alarm event if a threshold is exceeded (peg counts) or a burst signifies an error rate. Yet another type of client process might log or audit its events. The News Server must provide a programmatic interface (API) for clients.
Client processes must be capable of being adding or deleting themselves from the client list dynamically.
Client processes must be subject to a security scrutiny. The nature of this scrutiny will depend on the OA&M platform and needs further discussion.
Each client process can declare an interest profile and modify it dynamically.
The News Server must examine each event for significance to each client as determined by the intersection of its declared interest profile and security constraints.
When an event is found to be of interest to a client, the News Server composes a message and forwards it to the client. Composing a message involves one or more of:-
The News Server must support a programmatic interface (API) to post events. NAP components capable of posting events must include (i.e. the software must be modified or an agent must be implemented):
The News Server must support dynamically adding processes to the list of those permitted to post events.
( First published May 92, by David Bayly.)