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: Channel Access Client Interface
From: "Jeff Hill" <[email protected]>
To: "'Kay-Uwe Kasemir'" <[email protected]>, "'EPICS Core Talk'" <[email protected]>
Date: Thu, 11 Aug 2005 13:08:51 -0600
Kay,

I had a look at your proposal. Here are my comments.

1) First of all I am pleased to see that you are proposing an approach
interfacing (and describing) the user's data rather than another proprietary
way to store data (the GDD and cdevData approach). I would therefore
classify your ideas as a revision of the basic DA approach that is
compatible with our requirements from the highest level functional
perspective.

2) Your "issue" is that DA is less easy to understand compared to your
revised interface. Considering (1) above then the user will store (and
access) data in whatever local format he considers to be easy. Therefore,
the primary ease of use issue will be related to interfacing whatever the
user's storage format might be. The user can store his data in a linked
list, a structure, or in a relational DB. It doesn't matter how - it only
matters how easy it is to provide an interfacing object for the local
approach.

Let's look at storing the data in an application specific proprietary
structure. That will be the easiest approach for the author of an
application.

template < class VIEWER >
inline void MyContainer :: propertyTraverse ( VIEWER & viewer )
{
    viewer.reveal ( propX, ar_mutable, & MyContainer::x );
    viewer.reveal ( propY, ar_mutable, & MyContainer::y );
    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:

TestRecord::TestRecord() 
        : EpicsPropertyCatalogBase(3, properties)
{
    point_properties[0] = new EpicsDoubleProperty("x", &point.x);
    point_properties[1] = new EpicsDoubleProperty("y", &point.y);
    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. 

3) What remains is the interface for discovery of properties in unknown
data. This is an issue for system programmer designed tool such as MEDM,
probe, or the gateway. It is not an issue for application specific programs
such as an emittence measurement or a magnet ramping application. Therefore
we can expect a more sophisticated audience of the interface for discovery
of properties in unknown data. 

I think that we can succinctly boil this down to two options. Should this be
iterator based (I assume that with Kay's approach he would soon enough morph
to using an iterator) or callback based (the DA approach). Here are some
comparisons (believe it or not I originally thought very carefully about
this).

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,
are you signed, are you an array, what is your quest, etc, and then finally
ask it to convert itself to a double. With DA's overloaded callback based
approach is better because we are nearly instantly in code that is compiled
to know that we need to deal with scalar double - I don't have to ask and I
don't have to branch. 

O My first problem with the getProperty approach is item #29 in Effective
C++ 2nd Edition. We should avoid returning handles to internal storage. With
the callback approach we know that access to incoming arguments is only safe
for the duration of the callback as everyone expects with subroutine call
arguments. The interfaced object has good control over the lifespan of
access to its private members. The object knows when users are being allowed
to mess with its data. Furthermore, (THIS IS CRITICAL) the object can
guarantee that if someone attempts to modify two properties and the two
changes are inconsistent that an exception will be thrown and that no
properties will be changed (see the DA reference manual). Because of this
issue I am not inclined to create an interface in the propertyCatalog that
creates an iterator granting unconstrained access to the properties in the
catalog. Furthermore, you will note that the PropertyCatalog does not
currently even provide a writable version of find in the PropertyCatalog
interface because of similar concerns about allowing the class to control
property consistency. There are similar issues with implementation specific
limit checking - with the callback approach they have control (see the DA
reference manual).

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. If an iterator is needed for internal use by MEDM, probe, or
the gateway for that type of storage I don't see a problem with creating
one, but I would not routinely hand an iterator off for external use (cross
domain boundaries) due to the above concerns about loss of control of
consistency.

IMHO the DA introspection interfaces will typically be implemented by a
small number of system programmers when implementing a very small set of
system libraries. In this case performance and functionality is more
important than ease of use. Here are the only situations I can imagine that
we will need.

O In a support library that copies or compares between properly interfaced
data catalogs. 

O In a support library for a program like probe or the gateway which will
inflate storage dynamically to store copies of whatever properties the
server might have that are of interest. 

DA has support libraries (a non-trivial effort that has already been
completed) for the former, and the later is already in design by Ralph - it
should be a well bounded chunk of code. This probably means that users will
almost never implement the propertyViewer, PropertyManipulator, and
PropertySurveyor interfaces.

4) Kay's proposed interface does not allow introspection w/o an instance or
differentiation between const and non-const?

5) Kay's proposed interface to find is based on string compares. With DA the
find is based on integer property identifiers - which are more efficient. I
presume that you would quickly change your interface to be like DA in this
regard when creating an implementation.

6) Kay placed a common implementation of find in a base class. That's less
work for the user. We could do a similar thing with DA - creating a default
implementation of find based on a linear search implemented with the
traverse callbacks. That would be somewhat less efficient, but very easy for
users that don't care as much about efficiency. An interesting idea.

Jeff



> -----Original Message-----
> From: Kay-Uwe Kasemir [mailto:[email protected]]
> Sent: Tuesday, August 09, 2005 6:57 AM
> To: EPICS Core Talk
> Subject: Re: Channel Access Client Interface
> 
> On Aug 9, 2005, at 03:56, Ralph Lange wrote:
> > There are _two_ type spaces [or whatever term is appropriate]
> > connected to this issue, which are _separate_.
> >
> > 1. One type space contains the fixed set of native "server-side" types
> > that Data Access is going to support when transporting stuff - across
> > language and machine borders. We have to define this type space,
> > together with a clever implementation of a type designator, that
> > should be comprehensive and easy-to-use. (Kay's further discussion is
> > about this type space.)
> >
> > 2. The other type space contains some (probably a subset) of the Data
> > Access implementation language's basic types. These are the types that
> > a user application will use to store the data, so Data Access will use
> > these types in the interfaces and will convert between the language
> > and platform independent fixed types (last paragraph) to the types of
> > the user's data (this paragraph).
> >
> > It's not that difficult, is it?
> I think that's what I'm presenting on:
> http://www.aps.anl.gov/epics/wiki/index.php/V4_Data_Interface
> 
> The available data types are fixed & limited:
> The DataDescriptor interface will tell the user that it's an
> Integer with 16, 32, 64 bits,
> a Real with 32 and 64 bits, ...
> 
> You can get the exact type, for example a real64_t,
> but there's also room for 'convenience' routines
> that provide 'double' or 'int', the basic types of the
> language where the exact type isn't nailed down.
> 
> I'm also happy to repeat once more ;-) :
> 
> Do you (and Ben) think that an interface like the DataDescriptor
> with getType(), getBitsize(), .. would work?
> Or is it necessary to get a
>    struct { Type type, int bitsize, ... }
> as you suggested earlier?
> 
> As for actually getting the data, one group proposes data access
> pretty much as it is.
> 
> Marty suggested one interface per data type: NaInt16, NaInt32, ...
> That's similar to the current Java channel access.
> I find it inconvenient, because a lot of user code ends up looking like
> this:
>      double d;
> 	if (data.getType() == ...int16...)
>            d = (double) ((NaInt16)data.getInterface()).get();
>      else if (data.getType() == ...int32...)
>            d = (double) ((NaInt32)data.getInterface()).get();
>      ...
> So if one goes with a 'reader' interface, I'd prefer the
> DataReader on
> http://www.aps.anl.gov/epics/wiki/index.php/V4_Data_Interface:
>      /* try to get the value as double, regardless of native type */
>      double d;
>      if (reader->getDouble(d)) { /* OK */ } else { /* doesn't convert to
> double */ }
> 
> -Kay



Replies:
Re: Channel Access Client Interface Benjamin Franksen
Re: Channel Access Client Interface Kay-Uwe Kasemir
References:
Re: Channel Access Client Interface Kay-Uwe Kasemir

Navigate by Date:
Prev: Re: Channel Access Client Interface Benjamin Franksen
Next: Re: Channel Access Client Interface 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: Channel Access Client Interface Benjamin Franksen
Next: Re: Channel Access Client Interface 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 ·