Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: V4 design issue: Should primitive data types have well defined precisions?
From: Ralph Lange <Ralph.Lange@bessy.de>
To: Marty Kraimer <mrk@aps.anl.gov>
Cc: EPICS Core Talk <core-talk@aps.anl.gov>
Date: Mon, 27 Jun 2005 17:44:00 +0200
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.

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.

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


Replies:
Re: V4 design issue: Should primitive data types have well defined precisions? Kay-Uwe Kasemir
Re: V4 design issue: Should primitive data types have well defined precisions? Marty Kraimer
References:
RE: V4 design issue: Should primitive data types have well defined precisions? Dalesio, Leo `Bob`
Re: V4 design issue: Should primitive data types have well defined precisions? Ralph Lange
Re: V4 design issue: Should primitive data types have well defined precisions? Marty Kraimer

Navigate by Date:
Prev: Re: More flexible record scanning Andrew Johnson
Next: Re: V4 design issue: Should primitive data types have well defined precisions? Kay-Uwe Kasemir
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: RE: V4 design issue: Should primitive data types have well defined precisions? Jeff Hill
Next: Re: V4 design issue: Should primitive data types have well defined precisions? Kay-Uwe Kasemir
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·