Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Tue, 26 Jul 2005 11:49:11 +0200

Any comments or arguments about placing these requirements on CA?

  1. Each version of the CA protocol SHALL document which data
  types it supports for transporting properties over the wire.

  2. Each version of every implementation of the CA library,
  server or client, whatever language it supports, SHALL
  document which version of the protocol it supports, and how
  the on-the-wire data types from the protocol are mapped to
  the data types provided by that language.

  3. A client application written in any language SHALL be able
  to find out the on-the-wire data type which is used to send
  any specific property being received through the CA transport.

Note that in #3 I'm *not* requiring CA to be able to transport the

type of the property as implemented in the language of the server,

only the on-the-wire representation it supplies for that property.

Since different languages support different sets of types and may map

several different on-the-wire types to the same language-specific

type, some language implementations will have to to encode the

wire-type into something that can be represented as a *value* in a

language-specific data type. It would seem sensible to be able to

reuse the same value that is used internally by the network transport,

suitably converted.

I have the feeling we are mixing up things that belong to different

layers here.

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?

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

A CA (or any other network transport) server should be free to choose

the on-the-wire representation for any given DA accessible data, based

on the native types that it gets from the surveyor. It should

transparently forward the original native type info to the client side,

so that a client app gets the same results from the surveyor when

reading over the network as when reading locally.

Does that make sense?

Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System