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: "Jeff Hill" <[email protected]>
To: "'Marty Kraimer'" <[email protected]>, <[email protected]>
Date: Wed, 27 Jul 2005 14:19:26 -0600
> I keep hearing "size locked types should not be in interfaces used by
> users". This does not satisfy either 1) or 2).

I am not opposed to size locked types. They must of course be in the
protocol and so CA will need a set of type codes for size locked types. 

Perhaps I can boil down recent discussions about size locked types into two
areas.
1) Users should use size locked types
2) All EPICS code should use the same set of size locked types
3) Whether unsigned types should or should not be in this type set

WRT (1) above I see two types of users.
a) Users that would like to use the exact same size locked type as the
server
b) Users that would like to use the largest size possible for a particular
type and be informed if the magnitude of the server's data instance will not
be expressible in this type. I think that most of the users already use this
model. DA handles this model well, better than any interface we have used in
the past I believe because it detects out of range conditions when
converting, so perhaps we don't need further discussion here.

For (a) we can tell them one of the following
A) What "C/C++" type it is in the server i.e. the C++ type_info
B) Supply a type code from a new type code set identifying size locked types

In my example at the meeting I showed how DA could be enhanced to introspect
the structure of the data - w/o an instance of the data. I communicated this
information using an simple template class as follows.

template < class T >
struct TypedVoid 
{ 
};

I don't see any reason why the interface to this struct couldn't, or
shouldn't, be extended as Ralph suggested at the meeting, to include member
functions returning type codes for (B) above (it already does A). I will
make this change as soon as we agree on what type code set to use for B. The
only reason why I hesitate is that DA is currently compiling independently
of EPICS except for its entanglement with epicsTime. NAD would of course be
a 2nd entanglement. I will go with the NAD type set if the group is
unwilling to let it go the other way (where EPICS becomes dependent on a
size locked type set defined by DA). Since DA is smaller and more general
purpose than EPICS it seems natural for EPICS to be dependent on DA and not
visa-versa. By-the-way, the name " TypedVoid" is probably horrid (as Jim K
would say) and should be changed.

Furthermore, should the user write a DA interface for a structure with a
size locked type in it such as nad_float_128_t. The correct overloaded
reveal member function in DA will automatically be selected, and CA will
know internally what size locked type to use on the wire.

WRT (2) above I have no problem using someone else's (Marty's) size locked
type set in the CA protocol, but given the features in DA this would only be
a organizationally cosmetic benefit, but not a feature required to make sure
that the proper size locked type code for what the users is really using is
discovered by CA for its use on the wire. Of course the TypedVoid interface
(or whatever the correct class name is) should use a common type code set.

WRT (3) above I am not blind to the argument behind eliminating type
"unsigned" from user data passed over a protocol user interfaced from multi
languages. Perhaps one could rephrase this to say that unsigned types are
o.k., but we should not allow use of unsigned number whose magnitude is
larger than what can be expressed in an equal sized integer type in the
protocol. If that were true then the following could occur transparently.

O C/C++ server has native unsigned type whose magnitude is expressible as an
integer type.
O JAVA user (client) is told that the native type is an integer type
O unsigned to integer conversion occurs without loss of information

What do you think?

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




Replies:
Re: ICE and TIPC Andrew Johnson
Re: ICE and TIPC Marty Kraimer
References:
Re: ICE and TIPC Marty Kraimer

Navigate by Date:
Prev: RE: ICE and TIPC Jeff Hill
Next: next meeting before EPICS meeting at Archamps? Matthias Clausen
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 Jeff Hill
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 
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 ·