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: V4 design issue: Should primitive data types have well defined precisions?
From: "Dalesio, Leo `Bob`" <[email protected]>
To: <[email protected]>, <[email protected]>
Date: Wed, 22 Jun 2005 05:47:44 -0700
 From a functional point of view - the DA approach gives you total flexibility.
What does it do to the complexity of the implementation and the performance? 
Does it have an impact on the server? Or just the client side?

Bob 

-----Original Message-----
From: Benjamin Franksen [mailto:[email protected]] 
Sent: Wednesday, June 22, 2005 5:38 AM
To: [email protected]
Subject: Re: V4 design issue: Should primitive data types have well defined precisions?

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


Replies:
Re: V4 design issue: Should primitive data types have well defined precisions? Ralph Lange
Re: V4 design issue: Should primitive data types have well defined precisions? Benjamin Franksen

Navigate by Date:
Prev: RE: hello world examples Dalesio, Leo `Bob`
Next: Re: V4 design issue: Should primitive data types have well defined precisions? Ralph Lange
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: hello world examples Dalesio, Leo `Bob`
Next: Re: V4 design issue: Should primitive data types have well defined precisions? Ralph Lange
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 ·