Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Fri, 02 Sep 2005 17:18:47 -0400

Hi:

On Aug 11, 2005, at 15:08, Jeff Hill wrote:

I had a look at your proposal....

I've been busy but finally got around to try data access,
based on the Aug. 23 snapshot. The result is on
http://www.aps.anl.gov/epics/wiki/index.php/V4_Data_Interface

I think that we can succinctly boil this down to two options.

Should this be

iterator based (..) or callback based (the DA approach).

YES! I'm convinced that many find

    EpicsProperty *p = pc->findProperty("value");
    double d;
    p->getDouble(d);

easier to understand than handing control over
to a 'viewer' class

    Viewer v;
    pc->find(pi_value, v);

OK, data access visited the viewer's
reveal(pi_value, <native type>),
but now I have to hack around to get
the data deposited in a place that's accessible
from the line after 'find' where I want to
use the data.

Maybe dataAccess needs to include a set of these:

doubleViewer : public propertyViewer
{
public:
   double d;

 void reveal ( const propertyId &id, const double &v, const

propertyCatalog &x)

   { d = v; }

 void reveal ( const propertyId &, const int &i, const

propertyCatalog &x)

   { d = v; }
...
}

Now I could write

    doubleViewer dv;
    pc->find(pi_value, dv);
    cout "Value is " << dv.d

2) ....Let's look at storing the data in an application specific

proprietary

structure.

...

    viewer.reveal ( propValue, ar_mutable, & MyContainer::value );
    viewer.reveal ( propUnits, ar_mutable, & MyContainer::units );
    viewer.reveal ( propPoint, ar_immutable, & MyContainer::point );

...

Consider what the user has to do with Kay's revised approach:
    properties[0] = new EpicsDoubleProperty("value", &value);
    properties[1] = new EpicsStringProperty("units", &units);

 properties[2] = new EpicsStructureProperty("point", 2,

point_properties);

They look very similar in terms of ease of use to me.

Yes, very similar. Except when I actually try it with data access,
I run into 3 issues:
- the published version doesn't understand ar_mutable/ar_immutable,
  so I have twice the code for now
- don't know how to interface with stringSegment,
  so I had to skip the units.
- in order to reveal my struct point, it needs to be rewritten
  to derive from propertyCatalog.

Does DataAccess interface structured user data 'as is'?
I only get that to work for scalars.
Sub-structures need to re-packaged as propertyCatalog-derived
classes.

O My perception is that callback is more efficient. With the

iterator and

abstract data descriptor approach I have to play the animal,

vegetable, or

mineral game with the data. I have to ask the property what is your

type,..

Almost. As the end user of the API, I _may_ ask, if I care,
for example if I'm a generic dumper that wants to dump any data type.
More often I simply say: getDouble().
If my property happens to be an
EpicsDoubleProperty, I get the double.
The other EpicsXXProperty classes have this default conversion:
    bool getDouble(double &d)
    {
        int i;
        if (!getInt(i))  return false;
        d = i;
        return true;
    }
There is no 'switch(type)'.

Furthermore, the authors of MEDM, probe, or the gateway will

probably use a

common library (I think that Ralph is already in the preliminary

design

phase) for inflating storage for a set of properties that are

unknown at

compile time.

Yes, I think such a library is needed to make dataAccess usable.

-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System