Experimental Physics and Industrial Control System
|
Subject: |
Re: V4 design issue: Should primitive data types have well defined precisions? |
From: |
Marty Kraimer <[email protected]> |
To: |
EPICS Core Talk <[email protected]> |
Date: |
Mon, 27 Jun 2005 11:34:43 -0500 |
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
- Replies:
- Re: V4 design issue: Should primitive data types have well defined precisions? Ralph Lange
- 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
- Re: V4 design issue: Should primitive data types have well defined precisions? Ralph Lange
- Navigate by Date:
- Prev:
Re: V4 design issue: Should primitive data types have well defined precisions? Ralph Lange
- Next:
connections, beacons, ...: Only directory and TCP? Kay-Uwe Kasemir
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: V4 design issue: Should primitive data types have well defined precisions? Ralph Lange
- Next:
Re: V4 design issue: Should primitive data types have well defined precisions? Ralph Lange
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|