Experimental Physics and Industrial Control System
|
Marty Kraimer wrote:
On Jun 27, 2005, at 10:44 AM, Ralph Lange wrote:
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.
I don't understand. The main feature of dataAccess *is* an introspection
interface. Always has been. From day one for the last five years. The
traverse() methods have been there for ages.
So: By supporting dataAccess I am supporting an introspection interface.
Of course.
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.
I disagree. And network or not is definitely not the point. DataAccess
doesn't have anything to do with network.
A Java client app must be able to use dataAccess to address stuff in a
C++ library. Locally on the same node, no network involved. Still I want
the Java client to be able to find out the native type of a property is
"unsigned int64" but use Java native types (e.g. a bitfield) in the
dataAccess interface.
For CA, the dataAccess list of well-known primitive types must be
accompanied by a description of how these primitives are sent over the
network. That way CA can be used as a network transport for dataAccess.
But separate things should be kept separately:
Data Access uses native types "outside" (in the API) and defines a list
of well-known size-fixed primitive types "inside".
Channel Access defines a network representation for these primitive
types and provides network transport for dataAcccess property catalogs.
Ralph
- 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
- Re: V4 design issue: Should primitive data types have well defined precisions? Marty Kraimer
- Navigate by Date:
- Prev:
Re: More flexible record scanning Benjamin Franksen
- Next:
Re: dataAccess V4 Ca client propertyId questions 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
- Navigate by Thread:
- Prev:
Re: V4 design issue: Should primitive data types have well defined precisions? Marty Kraimer
- Next:
Re: V4 design issue: Should primitive data types have well defined precisions? Benjamin Franksen
- 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
·
|