Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 28 Jul 2005 09:59:03 -0600

> Let me once more state what I think should be the requirements for
> extensible network accessable data.
> 
> primitive data types: bool, octet, int16, int32, int64, float32, float64
> string:  UTF-8 encoded chars

A) I mentioned yesterday that I am willing to supply a type code for the
native type in a size locked type code space. Ralph mentioned that this
might be a good idea at the last meeting, but I had not yet had a chance to
consider the issue further until yesterday.

B) All data transferred over the wire will be in size locked types. There
has never been any question about this - in previous or future versions.

C) The user may use size locked types if he wants. CA (via DA) will know
what type size the user has chosen irregardless of whether he uses size
locked types or not.

My perception is that this covers any possible problems that might occur
because size locked types are not used.

> primitive data types: bool, octet, int16, int32, int64, float32, float64
> string:  UTF-8 encoded chars
> 
> In addition array and structured data must be supported. Perhaps
> 
> array: 1 dim array. The field types can be primitive, string, array, or
> structure
> MDarray: multiple dimensioned array of primitive type
> struct: ??? If dataAccess is used perhaps this is just a propertyCatalog.
>

I am confused. I think that you are aware that DA already has interfaces
supporting multi-dimensional array data, and structured data?

> The following is not very satisfying:
> 
> template < class T >
> struct TypedVoid
> {
> };

The name of this example class identifying the native type definitely needs
to change (I mentioned this yesterday, and none of this code is in a manual
or in any version of DA at this time). Likewise, as mentioned above and also
yesterday, there will be a method added returning the native type in a size
locked type code space.

> Even if something is defined in C++ it should be easily converted 
> to a Java definition.

As I mentioned before, I don't see anything in DA that couldn't be written
also in JAVA. For example, templates make it easier to implement the code,
but they are not required in an implementation (even if JAVA now has them).
For example, if you don't have templates then you just create a different
class for each type. With GDD and predecessor codes Jim and I didn't use
templates. We chose instead to computer generate the conversion matrix code.
I am more than willing to discuss specific situations that you can identify
as being a problem with a Java implementation.

> The implementation (of DA) is so good that EPICS V4 must adapt it as is.

We are very willing to discuss any specific issues that you have with the DA
interfaces. For example, I am adding routines returning native type mapped
into a size locked type code space, and I am responding to questions raised
about every string being an iterator.

Jeff

> -----Original Message-----
> From: Marty Kraimer [mailto:[email protected]]
> Sent: Thursday, July 28, 2005 7:15 AM
> To: [email protected]
> Subject: Re: ICE and TIPC
> 
> 
> 
> Jeff Hill wrote:
> 
> >
> > Since DA is smaller and more general
> >purpose than EPICS it seems natural for EPICS to be dependent on DA and
> not
> >visa-versa.
> >
> >What do you think?
> >
> >
> 
> 
> Perhaps this is the real reason why we have so much trouble finding
> common ground.
> 
> Two viewpoints:
> 
> 1) dataAccess is the core for all data passing. A key feature is that,
> for each language implementation, it must support all primitive types.
> 
> 2) For network accesssable data a key requirement is to define a set of
> primitive types that can be widely supported.
> 
> The dataAccess camp says that 2) is not really important.
> Others, at least me, say that 2) is VERY important and the key feature
> described in 1) should be modified to say "network primitive types"
> instead of "all primitive types".
> 
> Let me restate 1) in another way that I think does reflect the thinking
> of at least Jeff, Ralph, and Benjamin.
> 
> dataAccess is really a great idea and has a really great C++
> implementation. The implementation is so good that  EPICS V4 must adapt
> it as is.
> 
> Let me state 2) another way that reflects my thinking and possibly others.
> 
> If dataAccess is not willing to change for EPICS V4 then maybe we should
> just abandon dataAccess.
> 
> 
> Let me once more state what I think should be the requirements for
> extensible network accessable data.
> 
> primitive data types: bool, octet, int16, int32, int64, float32, float64
> string:  UTF-8 encoded chars
> 
> In addition array and structured data must be supported. Perhaps
> 
> array: 1 dim array. The field types can be primitive, string, array, or
> structure
> MDarray: multiple dimensioned array of primitive type
> struct: ??? If dataAccess is used perhaps this is just a propertyCatalog.
> 
> 
> In addition It should be possible for a client to easily introspect the
> data types provided be a server.
> The following is not very satisfying:
> 
> template < class T >
> struct TypedVoid
> {
> };
> 
> One other thing bothers me. Much of the discussion is VERY C++ centric.
> But most of what we want for EPICS V4 should be implementable in at
> least C++ and Java. Even if something is defined in C++ it should be
> easily converted to a Java definition.
> 
> 
> Marty

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System