Re: Identifying normative types

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

Hi Ben,

On 2012-03-02 Benjamin Franksen wrote:
> The question then arises how else to identify NT classes or types?
> 
> I see three principle possibilities:
> 
> (1) use fixed type IDs
> (2) infer the NT class, based on the introspection interface
> (3) add some new mechanism
> 
> ad (1): Using the type ID in the protocol is impossible as long as the NT
> classes contain an infinite number of types. The reason is that the type ID
> must be unique per single type, not per NT class. The only way around that
> is to drop the requirement that says a NT may have an arbitrary number of
> additional fields. If we do this, the number of NTs per NT class becomes
> finite again, and we can use a fixed numbering scheme.

I don't think that restriction would be acceptable.  I agree that we can't use 
fixed type IDs.

> ad (2): While NT class inference is, I think, possible in principle, it
> means one has to be very careful when designing the NT classes to preserve
> this property (i.e. that NT classes can be infered from the introspection
> data). It is also quite inefficient.

Agree about the inefficiency here, but see below.

> ad (3): This means extension of the protocol with a new member (probably of
> type int) for the structure introspection serialization plus special
> methods in the classes of the API. For instance, Structure needs a new
> method, something like 'int getNormativeType()' which can be looked up in
> some fixed static table.

I'm not sure how you pass that kind of thing over the network, and you're 
still using an integer to identify an NT, so I'm confused about what you're 
suggesting (but I probably don't need to know anyway).

I think there is a better way, but I'll come back to that in a minute.

Stepping back a bit, what are we trying to achieve with the Normative Types?  
We want a V4 client or server to be able to embed something in a PVData 
structure (or in its structure description) that efficiently identifies its 
logical structure as complying with the published standard for one or more 
Normative Types.

Some NTypes may be subsets of other NTypes, and we shouldn't force a client 
that uses the more generic type to know the names of all the subtypes that it 
could also understand, so I suggest we should allow the identifier to include 
more than one Normative Type that it complies with.  This would allow us to 
use identifiers more like traits or roles, instead of having lots of optional 
fields.  For example we could have a trait "hasAlarm" which requires that the 
object have a top-level alarm_t field named alarm.  Now we can remove that 
optional field from all of the other NType definitions.  An alarm handler can 
thus connect to any channel whose data complies with the "hasAlarm" trait.  A 
display manager can look for the "hasAlarm" trait to determine whether a 
channel can be displayed using alarm colors or not.

Here are some of the other possible traits, from a quick look through Greg's 
latest document:

hasDescriptor
hasAlarm
hasTimestamp

hasScalarValue
hasArrayValue
hasEnumValue

hasUnitsString
hasDisplayLimits
hasAlarmLimits
hasControlLimits

hasImageData
hasImageMetadata
hasImageAttributes


Now we have a list of traits instead of a list of Normative Types.  I think it 
is reasonable to assign each trait a small fixed integer (16 bits?), so now a 
traits check involves doing something that looks a lot like comparing two 
bitsets, or looking at individual bits in one.  Depending on how many traits 
we end up with it might be more efficient to be able to transport the traits 
list as either an array or as a bitset, so I would not recommend that we say 
it _must_ be a bitset.


Is this better?  I think so, but it does mean a complete rewrite of the NTypes 
spec...

- Andrew
-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte