Re: [Pvmanager-devel] alarm

[Ralph L. <Ral...@be...>]

  On 01.09.2010 11:55, Benjamin Franksen wrote:
> On Mittwoch, 1. September 2010, Dalesio, Leo wrote:
>> What we want -
>> something that gives more information than that.
> I disagree. We need not more, merely more specific information.
>
> A fixed set of choices for severity is good. When writing support for
> devices (whether at the device support level or, for more complex devices,
> at the database level) I never had any problem deciding which severity to
> assign to the several possible alarm states(*). In fact, I find the
> limitation to a small number of fixed choices actually helps, as it makes
> you think harder about what exactly the different alarm states mean for the
> user.

I think only Andrew has a different opinion about severity, because his 
idea drops status completely and merges the information into severity.

I would say enum or int with enum usage is a minor issue.

> Things are quite different for alarm status. Fitting the alarm states of a
> device into the pre-defined set of choices always feels like forcing it
> into a straigh-jacket. It never feels like it fits right. Having more
> freedom here would be very valuable. The question is how much freedom we
> want. An arbitrary string value for the alarm status would be maximum
> freedom, but imposes no structure at all. Maybe we want to impose *some*
> structure. Ideally, I would want an enumeration type, but one I can define
> myself. I also want o define it at several different levels.

Completely agree with that.

I would also say that each of the enum choices should have a severity 
linked to it (the severity that this choice would pull the record to).
The problem with that: record instances can differ in the severity they 
attach to the enum choice. (As records can be configured wrt severities 
for level alarms, disable status, simulation mode etc.)
So separating the array of status choice severities from the string enum 
would allow a higher degree of sharing immutable string enums between 
record instances with the same combination of record type and device 
support. (Or would that be premature optimization?)

> For instance, a driver or device support could define a set of choices for
> the alarm states of a certain ('atomic') device. However, such a device is
> often just a small part of some larger (logical) device, which one programs
> at the database level. In that case I want to be able to define my own set
> of choices for the alarm states of the complex device at the database
> level.

The record support will also want to add its choices to the enum, for 
all generic conditions that may occur while it processes.

~Ralph

> (*) What is the plural of 'alarm status' (in English)?

alarm statuses