Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Tue, 26 Jul 2005 13:05:46 -0500

Ralph Lange wrote:

While I generally agree with your requirements and descriptions, I don't

think we should make the network layer's on-the-wire types the central

type-defining instance. Let me give two reasons:

1. Learning the native type of data is part of the DA interface. The DA

interface is purely about data and does not have any notion of network

transport. An application may access things within a library or through

shared memory using DA without any network involved. Why should a

certain network layer define the data types when no network is used?

I'm not convinced that it's possible for us Muggles to do that

(translation: I think you're asking for magic).

I can create a DA container that has a property expressed in a new

application-specific 'absoluteTemperature' type. This is implemented as

a C++ wrapper around a double; it provides an implicit conversion to

double operator, and also has constructors and assignment operators that

take doubles. The type express an absolute temperature in Kelvin, and

the accessor functions ensure it can never holds a negative value. The

property type is definitely not a double though, and C++ is perfectly

capable of distinguishing the two.

Inside Data Access, each supported type has an overloaded reveal() entry

in the virtual function table of the propertySurveyor, propertyViewer

and propertyManipulator interfaces. If I want Data Access to natively

support my new 'absoluteTemperature' type, I have to extend those

interfaces and add a new reveal() function to all of the standard

surveyor, viewer and manipulator helper classes (converters etc).

That's a lot of work, and now I have a problem - I've changed the

signature of those propertyXxxx interfaces, so I can't link my version

of DA with the standard CA library any more.

Thus unless I modify Data Access and then completely recompile both DA

and CA, no other local DA object can know what my new type really is -

as far as they're concerned my absoluteTemperature properties would just

look like doubles. Unless I extended the CA protocol too, CA would

still have to transport them over the network using doubles and would

not be able to tell the difference (assuming the current interface).

2. Not only may a language map different on-the-wire types to the same

language-specific type, CA (or another network layer) itself might

consider to map different language specific-types to the same

on-the-wire type. In that case I would like the client to know the real

original native type of data on the server side and /not/ what something

inbetween chose to use for network transport.

I'm not convinced about the usefulness of this in practice - you don't

have any control over how the value gets transported. Even if you ask

for it as a string, the conversion will happen at the client end with

the V4 version of CA.

I see the next generation CA as a transparent network transport layer

for DA accessible data, so that the DA interface works the same local

and via network. A client application should not have to know and should

not even care what on-the-wire types CA uses to transport stuff.

I agree that a client shouldn't have to know that the network types are,

but that's not the same as saying DA has to be able to support every

data type. There will always have to be a mapping between a client type

and some network representation of values in that type.

I'm not saying that DA should *only* support the network types. I think

the propertyManipulator class should support all of the basic types

provided by the language, i.e. on C++: both signed and unsigned versions

of the integer types char, short, int, long and (if the platform

provides it) long long; float and double, and again if the platform

provides it long double too. However the propertyViewer does (and

should continue to) take advantage of the C++ type promotion rules to

reduce that list significantly, and it is this set of types (plus the

additional EPICS-defined ones) which IMHO CA should support as network

types.

I.e., we still need a well-defined extensible set of data types and

should continue the discussion how this should be implemented. But: I

would rather like to keep that set-of-types definition completely

independent from CA.

Then how are you going to solve the problem of adding new overloaded

reveal() virtual functions without recompiling CA for every client

application you build?

- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System