Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Wed, 27 Jul 2005 15:43:40 -0600

> 2) The ability to instrospect in a convenient manner.

Typical clients will just ask the system for the properties that they need
depending on the type of channel they are interfaced to. For example, for PV
channels clients might ask for the value, the alarm status, and the time
stamp. It will be sufficient for this type of client to interface their
structure (or class) using DA interfaces and then they can get what they
need by making an assignment between property catalogs. This is more
convenient than any form of introspection. Note that we need to interface
the data only once in the code. After that assignments occur much more often
in the code and they are very convenient. Since there will be a well defined
set of properties for different types of channels then less sophisticated
users may find that they can select data structures that have already been
interfaced to DA out of libraries thereby avoiding any need for interfacing
- should they find that to be at all difficult.

For clients such as Burt that need to place a line on a screen for all
supported properties they can just build a list of property describing
objects, adding an item of a particular type to a list for each primitive
type of property that is revealed. 

Which one is more convenient of callback-based or iterator-based? That's a
matter of personal perspective I think. This is like asking which is better
ca_get, or ca_get_callback? 

What is clear to me is that ca_get can be layered on ca_get_callback and so
the most primitive interface is ca_get_callback. Similarly, I can interface
very efficiently with code that has compile time knowledge of the structure
of the data using callback-based (raw DA). There are overloaded reveal
callbacks for each primitive type and so very efficiently we are in code
with compile time knowledge of the type. Note that copying between
propertyContainers is part of the design for the CA event queue so it must
be very efficient. With the iterator based approach the iterator data
structure needs to be constructed and maintained. With the traverse approach
the data interfacing code reveals the properties one after another and so no
state needs to be constructed or maintained.

Nevertheless, to support probe, the GW, and other codes that like to save a
copy of unknown property set and iterate through it we can write a library
module that copies all properties out of a propertyCatalog and places a copy
of them on a linked list. I think that Ralph is already starting to throw
together a design for this module?

The bottom line is that DA supports both compile time bound and run time
bound with the same interface making it appear to be the lowest common
denominator interface.

Jeff

> -----Original Message-----
> From: Marty Kraimer [mailto:[email protected]]
> Sent: Wednesday, July 27, 2005 11:41 AM
> To: [email protected]
> Subject: Re: ICE and TIPC
> 
> 
> 
> Ralph Lange wrote:
> 
> > Marty Kraimer wrote:
> >
> >> [...]
> >> Like CORBA ICE defines a language (Slice - Specification Language for
> >> ICE) and compilers that generate source files for several languages:
> >> C++, Java, C#, Visual Basic, and Python.
> >>
> >> The Basic Slice types are: bool, byte, short, int, long, float,
> >> double, string
> >>
> >> In addition it provides enum, struct, sequence, and dictionary.
> >>
> >> [...]
> >> Question: Why don't we just use ICE for communications for EPICS V4?
> >>
> >> We could provide Slice definitions for everything we want predefined
> >> and allow Dynamic Invocation for everything else.
> >
> >
> > One of the central goals of DataAccess was to avoid declaring
> > predefined types in a special language that is used to generate source
> > code. The idea was to have user defined compound types that client and
> > server agree on at connection time (not at compile time) and that
> > still get transported as effectively as predefined types during runtime.
> 
> 
> See below.
> 
> >
> > See the paper that Jeff was presenting at the ICALEPCS 2001
> > (http://arxiv.org/abs/cs.ni/0111026) for a discussion of the
> > underlying ideas.
> >
> > Help me: What were the reasons for not using CORBA for EPICS?
> > Why do none of these reasons apply to ICE?
> 
> 
> As I recall CORBA had two major defects that ICE does not have.
> 
> 1) The ability to batch messages
> 2) An efficient way to send monitors from a server to a client.
> 
> >
> > Just curious what's behind this 180 degree turn, that seems just a bit
> > all-too-sudden to me....
> 
> 
> Looking at past core-talk messages I found one I sent on Feb 21 2005.
> I think it shows that I have not done a 180 degree turn.
> 
> I still maintain:
> 
> 1) For network accessable data we want well defined types. In particular
>     a) primitive types:  bool, octet, int16, int32, int64, float32,
> float64
>     b) other basic types:  string (UTF-8), struct, array
>     c) convience types: enum, map, timeStamp. These are composed from
> primitive and basic types.
> 2) The ability to instrospect in a convenient manner.
> 
> I keep hearing "size locked types should not be in interfaces used by
> users". This does not satisfy either 1) or 2).
> 
> 
> This is part of what the Feb 21 2005 message contained.
> 
> Jeff Hill wrote:
> 
>     Hello Marty,
> 
>     Here are my comments.
> 
>     Yes, PP should be on the list for next rev of CA.
> 
> Primitive Types
> ---------------
> 
> 
>     o Past versions of CA were based on size locked types - i.e.
>     "typedef epicsInt16 dbr_int_t;". However, my experience is that
>     users seldom bothered to use dbr_xxx_t, and my current
>     perspective is that size locked types should not be in interfaces
>     used by users. Data access is an example of an interface that
>     binds to the user's selected primitive data type instead of
>     requiring that users recode to yet-another size locked data type
>     system.
> 
> o Data access is more fool proof because it uses overloaded
> functions instead of a data type code and a void pointer.
> 
> 
>     o We can generate C and Java bindings for data access as needed.
> 
> 
> Don't these, or at least the set that reproduces V3 functionality, need
> to be defined now?
> 
> The problem I have with Data access is that it seems to be a solution to
> a set of undefined requirements.
> 
> Let me focus the problem a little more.
> 
> What will the V4 Gateway be? How will it store data?
> 
> I think that answering these two questions will go a long way to
> deciding if and how Data access is a necessary component.
> 
> o Data access supports safe conversion between all of the
> primitive types available in C. If the source is out of range for
> the destination the operation is not performed and an error is
> returned to the user. This has already been implemented.
> 
> 
> Is this what we want?
> Let me give an example
> 
> 
> An IOC has a field that is an unsigned 32 bit integer.
> A java application asks for the fields as a signed 32 bit integer.
> The java application only uses the field as a bit mask.
> 
> 
> Should CA return an error if the value happens to have the high order
> bit = 1?
> I say no.
> 
> For an IOC perhaps we should just not support conversions that can cause
> problems.
> This is what I proposed in "EPICS V4 epicsTypes".
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System