Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Wed, 27 Jul 2005 13:25:05 -0600

> 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.

The problem with IDL is that the language allows fields in structures to be
defined but it does not allow the system to know what the field is used for
- what its property name is. With IDL type systems the set of properties
(parameters) sent with a message (structure) are fixed. They must either
match identically between client and server or else the description of the
structure of the data must accompany every instance of the data - every
time. With DA and future CA protocol the description of the client's
hierarchy of properties and their size locked types is sent to the server
only once the first time that the client uses the aggregate type. This
allows the server to post events with properties that the client isn't
requesting either because the server is newer than the client, or because
the client isn't interested in every single property and wants to save
bandwidth. 

Here is a usage case from LANSCE. LANSCE specific device support supplies a
"beam flavor" property with the signal value. When the database posts the
subscription update event it augments the database field's subordinate
properties with the property set supplied by device support. Specialized
clients can subscribe for a particular flavor of beam. Old clients continue
to work unmodified. We need this. In fact there are people her advocating a
branch for this purpose if V4 isn't going to be ready in time.

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