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: ICE and TIPC
From: Marty Kraimer <[email protected]>
To: [email protected]
Date: Wed, 27 Jul 2005 12:40:50 -0500


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




Replies:
RE: ICE and TIPC Jeff Hill
RE: ICE and TIPC Jeff Hill
RE: ICE and TIPC Jeff Hill
Re: ICE and TIPC Ralph Lange
References:
ICE and TIPC Marty Kraimer
Re: ICE and TIPC Ralph Lange

Navigate by Date:
Prev: Re: ICE and TIPC Kay-Uwe Kasemir
Next: Re: ICE and TIPC Andrew Johnson
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: ICE and TIPC Ralph Lange
Next: RE: ICE and TIPC Jeff Hill
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 ·