Re: [Pvmanager-devel] alarm

[Marty K. <mrk...@co...>]

  On 09/03/2010 06:59 AM, Dalesio, Leo wrote:
>
> I am attaching a couple of slides that attempt to describe what is 
> being proposed (and I thought we had agreed to) at the meeting we had 
> at BNL.
> It changes the alarm status to a bitset. Multiple alarm statuses are 
> true at the same time - which reflects real life.
>

I agree that being able to expose device status info to CA clients is a 
desirable goal. Where I have a problem is making it a required component 
of alarm.

This is a generic issue: Should of set of components be presented as a 
single object or as a set of objects. For a client this means presented 
as a single interface or as a set of interfaces.

The following are three example of where this issue has been the basis 
of heated arguments.

1) The javaIOC allows each field to have optional support. For example 
the scan field has scan support. An input field can have any of a large 
set of supports attached. In fact an input field could have 
linearConvert support attached and have a subfield named input that can 
again have any of a large set  of different supports to get a raw value. 
A valueAlarm field can have valueAlarm support attached. And so on an so 
on. The issue is how to construct a database record. One way is the V3 
way, which means that a set of basic record types, with each type having 
a fixed set of fields. Thus record types ai, ao, bi, bo, mbbi, etc. 
Another way is to construct a record based on what it does. As an 
example a record template can be created based on: 1) the specific 
device, 2) the communication bus, 3) valueLimits if they make sense, etc.

2) pvManager data, i.e. value, timeStamp, alarm, and display. How should 
this be presented to the client? One way is a fixed set of interfaces 
like DoubleTimeStampAlarmDisplay or as a set of interfaces like 
Double,TimeStamp,Alarm,Display.

3) Alarm. This is the issues currently being addressed. Assume there are 
three components severity, message, and deviceStatus. I know this is has 
not been agreed upon as the three components but it is details. The 
issue is how is the presented to a client: As a single interface named 
alarm that has all three components or as multiple interfaces. Thus this 
is really 2) appearing at a different level.

I am going to start another thread giving arguments why I think a set of 
objects is much better than a single object. The thread will concentrate 
on 2) but the same arguments can be made about 1).