Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Thu, 28 Jul 2005 11:26:01 -0500

I am leaving work soon and will not be back until Monday Aug 8th. Thus

the fact that I will not respond for awhile does not mean I have ginben

up or lost interest!!!

Jeff Hill wrote:

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?

For arrays I still wondet if 1dim arrays should be a special case

because they will be used far more often than multidimensional arrays.

Since we are only talking about network accessable data, it is possible

to define and implement "convience wrapper" for 1dim arrays.

For structure I agree that dataAccess provides this via propertyCatalogs.

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.

Good. Glad to hear it. Of course I want to see details.

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.

I agree that dataAccess as defined by the latest headers could be

translated to Java.

I just want to make sure new dataAccess features dont lead to problems.

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.

Good.

Marty

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