Re: [Pvmanager-devel] alarm

[Andrew J. <an...@ap...>]

On Wednesday 01 September 2010 12:45:10 you wrote:
> >I agree with *most* of that, but my ideal would still be a string.
>
> I think that the string makes life easier for the generator of alarms. I
> think it makes the clients that would use it much more complicated.

What clients are going to make use of this?  As I said yesterday (and Marty 
confirmed this morning) we only know of one client (ALH) that uses the V3 
status enum, and all it really does with it is add it to the alarm log-file.  
It can log a string just as easily as an enum, and the result would be much 
easier for operational staff to use to track down the problem.

> It does give ultimate flexibility. OTOH, it sends a lot more over the
> network.

.. for those clients that request the string.  If the only client requesting 
alarm message strings is the one that is responsible for logging the alarm 
status messages, I think that's appropriate use of bandwidth and not going to 
be a major drain on resources.

It /would/ be a mistake to insist (by the way the protocol and APIs are 
designed) that every client that asks for the alarm severity has to get the 
status message strings as well.

> It
> also requires all clients to have to parse the strings. The number of enums
> for status would be a limited set. The enum also gives an idea of what
> COULD go wrong. I can show the possible alarms and indicate which are true.
> Knowing the possible alarms also gives you some information that a NULL
> string does not.
>
> strings as alarms seem to me more appropriate for error logs, not alarm
> systems.

Will somebody please name/describe the client(s) that will have to ask for and 
parse the alarm status information.  There seems to be some unspoken 
requirement that neither Marty nor I know about.

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte