Experimental Physics and Industrial Control System
On Jul 15, 2005, at 08:51, Marty Kraimer wrote:
At this week's meeting I think we agreed, except perhaps Jeff, that we
want to define a set of well defined types
For the record, it's not just that we want to.
- We have to -
Assume a data source has these properties:
data { double value
string units }
and a client asks for "value" and "units".
A double and a string will go over the network.
The current DataAccess proposal fully encapsulates the data.
It won't disclose that there's a double and a string,
it doesn't provide references (pointers) to the raw data.
Instead, the receiver is supposed to provide the
storage in a format chosen by the receiver, e.g.
storage { int value
string units }
and "reveal" it via a property catalog.
storage::traverse()
{ reveal("value", value);
reveal("units", units);
}
DataAccess will then assign matching properties,
using a hash table of property IDs, C++ overloading and
templates to efficiently invoke the appropriate code:
int value(storage) = double value (incoming)
string units(storage) = string units (incoming)
OK, that's fast and OO compliant since the 'data' is fully hidden.
But: Since the user doesn't know the native type, so he might create
the wrong storage:
double data -> int storage: loose accuracy
string data -> double storage: loose the whole information
So if we want to write a probe-type tool that displays any PV
using a textbox for strings and a bar graph for numerics,
based on the underlying type, it needs to be able to query
the underlying type.
1) nad (network accessable data) is used instead of epics.
Is this a good name?
If not what is a better name?
Can we call it "epicsData" and use that everywhere;
Records, CA, ...?
-Kay
- References:
- Network Accessable Types Marty Kraimer
- Navigate by Date:
- Prev:
Re: Network Accessable Types Tim Mooney
- Next:
Re: Network Accessable Types 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
- Navigate by Thread:
- Prev:
Re: Network Accessable Types Tim Mooney
- Next:
Re: Network Accessable Types 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