Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Mon, 25 Jul 2005 18:31:02 -0400

On Jul 20, 2005, at 15:37, Marty Kraimer wrote:

Attached is a set of interfaces for network accessable data which has

the following attributes:

1) It provides introspection of primitive types, arrays, and

structures.

2) It could be implement easily in Java and C++

3) Nothing is implied about how to create storage for data, onlu how

to access it.

..

Hi:

Sorry I tuned out off the core-talk discussions for a while.
Being out of ideas, I looked at the NextStep/Apple Cocoa frameworks.
I like how it uses separate classes for static and mutable objects,
and suggest that the basic 'String' is read-only,
a 'MutableString' allows write access,
and there are container classes that create a string from char *,
sprintf-format etc. and present a 'String' or 'MutableString' interface.

We all seem to agree on getting basic type info,
using interface classes that might not hold the actual data,
and the fact that the actual data types will depend
on the language (C++, Java, maybe more).

I think Jeff's concern about locked types is important.
Few programs use dbr_double_t with DBR_DOUBLE etc.

In many cases, the point of knowing if it's an "Integer", "Double" or

"String"

is not that I want to use that exact locked type.
Instead, I want to know if the fundamental character of the value is
a number or a string,
maybe discrete number, floating point number or string,
so that I can manipulate it via up/down buttons,
sliders or text boxes.

So I see more use in abandoning the huge enum in favor of
a simple enum combined with a type descriptor interface,

similar to what edm uses and a bit like what Ben, Ralph and recently

Doug

suggested, I think:

enum
{
   Octet,     // Raw data,known to a server/client pair, but no one else
   Bool,
   Integer,   // Discrete
   Real,      // Floating-point
   String,    // UTF-8
   Enum,      // >=0 Integer with state names
   Struct,
   TimeStamp  // For efficiency?
} EpicsDataCharacter;

interface EpicsDataDescriptor
{
   EpicsDataCharacter getType();
   int getBitsize();      // bits of integer, ...
   bool isSigned();       // Integer might be unsigned
   int getNumDims();      // Scalar, vector: 1, matrix: >1
   int getSize(int dim);  // Scalar: 1
};

A property becomes a named data descriptior,
interface EpicsProperty : EpicsDataDescriptor
{
   String getPropertyName();
}
Doug called this 'symbol'.
A property catalog is a list of properties.

For getting at the data, I agree with Andrew's recent requirements,

which mostly match Jeff's ideas of using the native types of the

language.

Data access, or whatever we call it, maps the original data into those

native types.

Marty suggested a large enum with one interface per entry in
the enum, basically pulling 'getXXX' routines as opposed to the
pushing 'expose' methods in data access.

I think our fundamental difference is in how we intend to
handle access order and network buffer wraparound.

The record has all the properties available. Code with access to the

record

can read all properties in random order.
When the client requests "value" and "units", the properties
might arrive in pieces via the network.
But shouldn't the CA library hide this from the client, and present
the "value" & "unit" data as a whole?
If this means that the CA client library needs additional buffers
for assembling the incoming pieces, how bad is that?

Thanks,
-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System