Re: "value" field in Normative Types. Facilitates CA ?

[White, G. <gr...@sl...>]

Thanks Marty, comments inline. Brutal summary at the end.

Cheers
Greg

On 24 Feb 2012, at 21:55, Marty Kraimer wrote:

> On 02/24/2012 01:56 PM, White, Greg wrote:
>> Co-editors of Normative Types,
>> 
>> Almost all the Normative Types now are defined as having literally a "value" field (by
>> that I mean its introspection name is "value").
>> 
>> This is true even when the function of the Normative Type has a good name for what we've
>> called the value. Egs, NTHistogram calls the counts field (the freq of each bin) the
>> "value", even NTImage calls important Array data the "value":
>> 
>> structure NTHistogram
>> ...
>>   long []     value        // The frequency count, or value of each bin.
>> 
>> structure NTImage
>>     scalar_t[]  value
>>     …
>> 
>> 
>> This seems nearly true of all Ntypes, but not quite (NTStatistic doesn't have a value).
>> 
>> Q:
>> Was this use of "value" deliberate? Were we trying to make it so a very simple minded
>> user agent could always extract one field called the "value" and get something sensible?
> 
> Will it be more confusing to users it the most "important" field changes 
> name from one normative type to another?

For the General Normative Types (NTScalar, NTEnum, NTArray) I can see calling the
prime field "value" in all of them. But for the Specific Normative Types (among them 
NTHistogram, NTStatistic) calling the prime field "value" would be sure to incite some
ridicule. So, if there is a very good efficiency or interp reason, I'd use "value", but 
otherwise I want the prime fields named functionally (counts, mean etc). 

> 
> 
>> 
>> If that wasn't the objective, or that isn't very useful indeed, I would change the
>> name of the value fields to their functional names.
> 
> I can see arguments both ways.
>> Would it be useful to keep to simplify implementation of a CA V3 reception of V4 NT data?
> 
> CAV3 clients can already get more than just a value field.
> 
> A pvName has the form:
> 
>     recordName.name.name...{options}
> 
> where
> 
> recordName
>     The name of a javaIOC record
> name.name...
>     Each name is a fieldName or propertyName or index as described in 
> package org.epics.ioc.pv. The final field must a scalar, an array of 
> scalars, or an enumerated structure.
> options
>     options are of the form "name=value". The options are described below.
> …

Of course, this isn't new information or contrary to the use case I was alluding 
to as sufficient reason to stick with all prime fields named "value".

My point was that, if we named the prime field of *every* Ntype "value", then
a trivial intermediate agent could "back cast" (1) any Ntype from pvAccess/pvData to
CA *without having to understand the structure or semantics of any of them*. It
would simply extract that field whose fieldName was "value" and forward only that.
It would be a cheap way to weak V4/V3 backward introp, by enabling all Ntype 
conforming pvAccess/pvData on medm screens and other ca user agents, with minimal 
modification to those existing agents. Possibly no modification at all!

For instance, one might even imagine a trivial gateway modification for exactly 
that, though a gateway modification could presumably spend the time to back cast 
v4 to v3 intelligently on a per NType basis. I just know Ralph is going to
yell at me for this. I'm ready. I bask in his condescension.

Summary. Question: should all Ntypes' prime field be named "value"?
Pros: Facilitates trivial user agents. 
      Might facilitate v3 - v4 interop by "back casting."
Cons: Physicists are going to call us stupid.


(1) "Back cast" is just my term I've found useful. It's not as specific as
narrow casting or down casting and without the OO overtones. I mean it as
"narrowing to a backward compatible form".


  
> 
> Marty
>> 
>> Cheers
>> Greg
>> 
>> 
>