Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Wed, 27 Jul 2005 15:31:34 +0200

Andrew Johnson wrote:

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).

Correct. But this was not my point.

Certainly: If you want to add a new native type - so that the client

finds out that some value is of type 'absoluteTemperature' instead of

'double' - you will have to extend the set and recompile everything.

Let me try to rephrase my point: I do agree - we should and probably

must have a standard set of "native" language-independent types that can

be handled by Data Access.

But: I want these to be independent and not tightly coupled to the

/network/'s on-the-wire types. If these types apply in cases where

there's no network involved, they shouldn't be called network

on-the-wire types - there is no wire.

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.

Sure - conversion will be at the client's end.

But the network layer is the only thing that should control how the

value gets transported!

The service (providing the original DA interface) does not know about

the servers (for different network transport protocols) that it will

register with. So the server has no idea about and no interest in

controlling the network format. It must know the language-independent

native type of its data and present it to the server. The server has to

decide how it is going to be transported - in some network protocol

dependent on-the-wire format that is wide enough, probably.

The client doesn't care about the network type or format and doesn't

want to know, either. It is only interested in getting the original type

description that the service was presenting to the server on the other

side. Conversion to local types will be done locally (i.e. in the client).

Let me give an example for this practice:

My "SuperWire" (R) protocol has a 32bit blob as the smallest addressable

and transportable unit.

So my SuperWire server will use 32bit integers as on-the-wire type for

all 8bit, 16bit and 32 bit integer types a service provides.

The client should nevertheless see the original "8bit", "16bit", "32bit"

types when asking for the native type of a property.

For SuperWire the list of network types is shorter than for other

transports (e.g., CA) - the client should still see original native type

and /not/ the on-the-wire network type that was used to transport data.

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.

Maybe this is only an issue of definitions and terms.

If you replace the term "network types" with "platform independent

types" I would probably sign your mail without further questions.

What do you think?!

Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System