Re: V4 design issue: Should primitive data types have well defined precisions?

[Marty Kraimer <mrk@aps.anl.gov>]

On Jun 27, 2005, at 10:44 AM, Ralph Lange wrote:

> Marty Kraimer wrote:
>
> > dataAccess does not define basic primitive data types such as int16, 
> > int32, int64. This means that unless something else besides 
> > dataAccess defines such types two data sources have no way to 
> > guranteee that their primitive data types are compatiblle. In fact 
> > for the exact same propertyId one source may store the data as a, 
> > int32 and the other side as a float64. With dataAccess alone they 
> > have no way of knowing except by some other means such as conventions 
> > about propertyIds.
> >
> > Since dataAccess does not define primitive data types, application 
> > code has no way to guarantee precision for data without some 
> > conventions on top of dataAccess. Thus if the application uses the 
> > type long it does not know if this is 32 bits or if it is 64 bits. 
> > For network applications it certainly seems desirable to have a way 
> > to guarantee precisions.
>
> I think we should distinguish between the system wide well-known 
> primitive data types and the types used in the interface.
>
> Iirc, at the SLAC meeting we were agreeing on an additional dataAccess 
> traversal() method that yields the complete property structure 
> together with the native types of the properties. (NB: And the access 
> rights info?!).
> Those native types have to be well-known, size-fixed types that have a 
> tag which is defined for the server and client side. So that the 
> server can show the correct native type if asked for. So that the 
> client can ask for and understand what's behind a certain property and 
> use a local type that is wide enough to hold the data.

I sent my last message before I saw this message. Thus you are 
supporting an introspection interface. Good.

> The types that dataAccess uses in its interface to the data, should by 
> all means be the native types of the language that a certain 
> implementation of dataAccess is written in.
> I would like a client app in any language to be able to find out that 
> a certain value's native type is "unsigned int32", but I would also 
> like the same client app to freely choose data types of its language 
> for its data instead of forcing all client data to be of type epics... 
> If the interface is to be simple, it must use the simple types of its 
> language.

For any info that goes over the network I do not agree. I think 
architecture independent types are what is needed.

Marty

> Bottom line: the supported well-known primitive data types and the 
> types that a certain implementation of dataAccess implements in its 
> interface functions are two pairs of things.
>
> Ralph