Re: Network Accessable Types

[Tim Mooney <mooney@aps.anl.gov>]

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 (mooney@aps.anl.gov) (630)963-1860
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.