EPICS Controls 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  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Network Accessable Types
From: Kay-Uwe Kasemir <[email protected]>
To: Marty Kraimer <[email protected]>
Cc: [email protected]
Date: Fri, 15 Jul 2005 16:32:29 -0400
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  <20052006  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  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
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 ·