Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Sat, 16 Jul 2005 01:33:13 +0200

On Friday 15 July 2005 14:51, Marty Kraimer wrote:
> At this week's meeting I think we agreed, except perhaps Jeff, that
> we want to define a set of well defined types for network accessable
> data.
>
> These types are used as follows:
>
> 1) Data that is meant to be network accessable should be composed of
> network accessable data types
> 2) A client should be able to discover the network accessable data
> types of the server's data.
>
> [...]
>
> The set of well defined types is:
>
>  enum NadType {
>     nadTypeUnknown,
>     nadTypeBoolean,
>     nadTypeOctet,
>     nadTypeInt16,
>     nadTypeUInt16,
>     nadTypeInt32,
>     nadTypeUInt32,
>     nadTypeInt64,
>     nadTypeUInt64,
>     nadTypeFloat32,
>     nadTypeFloat64,
>     nadTypeString,
>     nadTypeArray,
>     nadTypeMDArray,
>     nadTypePropertyCatalog,
>     // Following are usefull common types
>     nadTypeTimeStamp,
>     nadTypeEnum,
>     nadTypeMap
> };

We can write down enumerations like that all day long and it won't bring 
us any further. The real question is:

Q: How is a client supposed to find out how to store the data it wants, 
so that no information is lost?

Knowing that something is an array obviously isn't enough, you need to 
know how large it is and what the element type is. And then you must 
recursively ask how to describe the element types, and so on.

We want to send /structured/ data over the network and we don't want to 
have a fixed number of data types, that is what we have today in CA. We 
need a way to describe the structure and send it along with the data 
(yes, not each time, only whenever necessary). So why stick to this 
useless enumeration of 'types', of which only some really are types and 
the others are type /constructors/. A mere enumeration cannot specify 
what the arguments to the type constructors are.

There was up to now exactly one contribution on this list (and none on 
the wiki) that addressed the problem and it was in Ralph's message, 
titled "Re: dataAccess V4 primitive types", citing:

On Thursday 30 June 2005 14:00, Ralph Lange wrote:
> type         =   string                      1)
>                | timestamp                   2)
>                | signed (bitwidth)           3)
>                | unsigned (bitwidth)         3)
>                | float (float_format)
>                | struct                      4)
>                | array (base_type, size)     5)
>
> float_format = ieee32 | ieee64 | ieee80
>
> Annotations:
>
> 1) String should be a basic atomic type - regardless of its
> implementation.
>
> 2) For efficiency reasons (as timestamps are shipped around and
> handled all the time) the timestamp should be an atomic type that can
> easily be mapped and assigned to the EPICS supported C/C++ types.
>
> 3) A server or client app can choose any locally available data type
> that is appropriate and wide enough to store the data. Future wider
> integers are supported. As for signedness, alternatively there could
> be one integer type with another parameter giving the integer format:
> | integer (int_format, bitwidth)
> with
> int_format   =   unsigned |signed
>
> 4) This basic type is needed for properties that actually are a
> contained list of other properties.
>
> 5) base_type is another type_info. If we need a type where arrays do
> not start with element zero, size might be replaced by a (min, max)
> pair. Multi-dimensional arrays are represented as arrays of arrays.

We may discuss the details, and the end result may look quite different 
from the above first proposal, but please stop going back to this 
useless enumeration scheme again, it won't work. The type description 
must be structured itself, and even self-referencing in order to get 
the job done. And as soon as you really start thinking about how to 
represent /all/ the type information, the question of exactly which 
basic numeric types are included becomes a minor issue.

Ben

   "The wind is informing the trees," the nagual said quietly. 
"And the trees are adapting to the wind, to its energy moving 
through them."

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System