Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 22 Jun 2005 14:38:07 +0200

On Wednesday 22 June 2005 13:38, Marty Kraimer wrote:
> I will argue that the answer should be yes.
>
> epicsTypes is the proposed set of primitive types are well as
> proposed definition for string, array, and enum.
>
> Without agreeing on a set of primitive data types, including the
> precision of each type, mismatches between data sources and consumers
> can easily occur.
>
> Corba IDL, Java, and C# all use types short, int, long, float, and
> double but ALL define the exact precision for each. In fact they all
> use the sdame precision, i.e.
>
> short 16 bits
> int     32 bits
> long  64 bits
> float  32 bit IEEE float
> double 64 bit IEEE float.

According to DA philosophy the interface should /not/ enforce how 
clients or servers store /their/ data. 

I find this quite convincing: You cannot use a programming language 
productively if you are forced to store the programs data in some 
foreign format.

Jeff wrote some interesting things on IDL based approaches in the DA 
tutorial. Notably, IDL based approaches /have/ to nail down all data 
types, primitive as well as complex ones. DA was designed expressly to 
avoid having to do this.

About mismatches: The current dbAccess interface where conversion is 
automatic already risks mismatches all the time. You request a SHORT 
from a LONG field, well that's your fault. So far nobody seriously 
complained.

I assume that there /will/ be a way for the client code to find out 
native (server or network side) precision and select its storage type 
accordingly if necessary.

I suggest -- /especially/ in view of implementations in languages other 
than C/C++ -- that we will have a /different/ DA for each language, 
plus a DA-CA bridge to convert native to network types and vice versa.

DA itself should support whatever the language provides as primitive 
data types. That is, if language X has a native String type, then X-DA 
should support X-String; if X has native unsigned integers, X-DA should 
support them; if X has bignums, so should X-DA have.

Yes, strings may be a primitive type in language X. So we don't even 
have a clear distinction between primitive and complex data types. So 
what?

Let me give one instructive example:

The Perl-DA would have /no/ distinction between primitive 
types, /including/ strings, everything being a Scalar, period. Thus, 
any sane implementation of a Perl CA Client Library would have to 
auto-convert primitive types (including strings).

Yes, we probably don't want a native Perl CA Client Library. So this one 
will build upon the C++ version. However, it is by no means necessary, 
that a X-DA-CA bridge has to use all the available 'primitive' types.

Yes, at some point we will have to nail down CA network format. I 
suggest that primitive types for the network layer should be as rich as 
possible, /including/ unsigned types. Since each data transfer is 
initiated (originally) by the client, communication with a native Java 
client will simply never use those unsigned types, thus creating no 
problem for the native client. A native Java server, OTOH, will never 
expose unsigned data, so a client cannot request it, thus still no 
problem.

Cheers,
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System