2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: V4 design issue: Should primitive data types have well defined precisions? |
From: | Ralph Lange <[email protected]> |
To: | Marty Kraimer <[email protected]> |
Cc: | EPICS Core Talk <[email protected]> |
Date: | Tue, 28 Jun 2005 15:28:48 +0200 |
Marty Kraimer wrote:
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.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 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.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.
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