Re: [Pvmanager-devel] alarm

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

On Wednesday 01 September 2010 11:33:39 Ralph Lange wrote:
>   On 01.09.2010 11:55, Benjamin Franksen wrote:
> >
> > 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.

Ahh, no, I wasn't proposing merging status into severity at all (I might have 
written status when I meant severity or vice versa at some point though).

In its simplest form I would accept keeping the V3 4-value severity int/enum 
(No alarm, Minor, Major, Invalid) and replacing the V3 status enum with a 
string.

My more complex proposal was to replace the V3 severity enum with a bitset 
with one bit each for Minor, Major and Invalid severities.  The V3 status enum 
would then become either a single string, an array of 3 strings, or an array 
of 3 arrays of strings, depending on how you want to combine and transmit the 
individual alarm messages.  I admit this proposal is probably too far of a 
stretch, but it would allow more and better error information to be collected 
and associated with each record.

> > 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 to define it at several different levels.
>
> Completely agree with that.

I agree with *most* of that, but my ideal would still be a string.  This 
information is going to be logged and read by a human (who is also given the 
record's name, time-stamp and alarm severity), and I often want to give them 
additional information such as the actual input character I received that 
doesn't match the protocol I understand, or the reading I was given which is 
out of the legal range.  I can't sensibly include those kinds of things in an 
enum, even if I do get to define it myself.

> 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).

Don't like, for the reasons you already expressed.  Some statuses should 
always map to a particular severity, but many don't, so I don't like the idea 
of automatically linking the two.

> > 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.

Hence a string makes life much easier.

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