Experimental Physics and
Industrial Control System

Tim Mooney <[email protected]> · Fri, 15 Jul 2005 11:02:32 -0500

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.

epicsTypes was an attempt by Andrew and I to define such a set. Perhaps

using epics in that name made it seem to be a lot more than just network

accessable data types. The following is a proposed definition for the

well defined network accessable types that is an extension of what

epicsTypes defines. The main changes are:

1) nad (network accessable data) is used instead of epics.
    Is this a good name?
    If not what is a better name?

netTypeXxxx might be more transparent.  Nobody will guess that 'nad' has
something to do with the network.

2) It adds
    a) unsigned types
    b) property catalog
    c) time stamp
    d) map

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
};

Note that a char type is NOT defined because it is extremely difficult

or impossible to define a network accessable char data type.

Let me briefly describe these types

nadTypeUnknown - This is reserved for the case where the type is not

known. Well behaved sources of data will not present such data.

nadTypeBoolean - This will have the values false and true and is not

meant to be converted to any other nadType

nadTypeOctet - This is an 8 bit byte. It is NOT a numeric data type and

is not automatically converted to any other type

nadTypeInt16,...,nadTypeFloat64 - Primitive data types. The unsigned

types should not be used unless absolutely necessarry. An implementation

can convert between these types using the rules of the language being

used. Thus C++ uses it's conversion rules, Java uses it's rules, etc.

nadTypeString - A UTF-8 encoded character string..

nadTypeArray - An array. The elements of the array can be any of the

nadTypes except nadTypeUnknown.

nadTypeMDArray - A multidimensional array.
             What types are alowed?
              Perhaps only nadTypeOctet,...nadTypeFloat64?

nadTypePropertyCatalog - Is this the correct name or should it be

Struct? Using PropertyCatalog implys that we are agreeing the dataAccess

is the way data is transfered between network accessable components.

nadTypeTimeStamp - This is a "convience" type. It is provided because it

is so widely used.

nadTypeEnum - Again this is a convience type.

nadTypeMap - Convience type. If available, it will be widely used.

If these types are acceptable, then it will still be necessary to agree

about the details of each type.

Marty

Is there such a thing among these types as a counted string?  I mean a
string whose declared length may be larger than the number of significant
characters, but which cannot be null-terminated because it may contain
nulls (e.g., as part of a checksum).

--
Tim Mooney ([email protected]) (630)963-1860
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System