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
<2005>
2006
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
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|