Re: [Pvmanager-devel] alarm

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

We are making an alarm system.

What we have now:
1 alarm severity and the 1 alarm status that caused that severity.

What we want - 
something that gives more information than that.

Proposal 1
bit set on status... multiple status true at the same time.
this looses the clarity about which status caused the severity while giving all of the status that are currently true.
-- addendum 1 - send as a separate enum or array what severity is caused by each status
                     - argument - you see what each status contributed to the severity
                     - issue - you have this new data thingy that can change by changing the severity of crossing a limt from minor to major.
                     - there is a limited set of configurable alarm statuses - so maybe this is a small thing
-- addendum 2 - only send the index of the status that represents the current severity.
                      - argument - you have a net gain on information sent - same as V3 + all statuses that are true.
                                      - no new data types

Proposal 2
send strings
- argument - any device  may send any random string
- counter argument - any random strings should be handled as an error log, not as an alarm system. Alarms are well defined conditions that have been designed into the system that we may want to react to. Any error string (it would be helpful to have a use case here), is not a known condition that we can configure any reasonable response to. Putting in this mechanism will take care of some small case that we have not identified at the cost of giving useful structure that can be handled in a well defined way at the client side. We could send self describing alarms too - and that would handle anything that may occur - but it does not make for well behaved client development. 

It would be useful to get just this part of the argument to an end before we come up with the most efficient way to implement either. Implementation of the communication mechanism is not implementation of useful clients - so it is not enough that we can easily implement the mechanism. CORBA can easily implement any communication.

Let's continue on email. Otherwise, we should try to plan a time during the upcoming meeting to resolve this.