Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 22 Jul 2005 13:17:19 -0500

Marty Kraimer wrote:

Your argument seems to be that as support for 128 bit ints and floats

appears then magically thibgs will continue to interoperate. This is too

good to be true.

I agree that this can't work magically. When we decide to add support

for quadruple precision floating point numbers say, the CA network

protocol will have to be extended to support them. Under the hood, Jeff

will have to add another value to whatever internal representation he

uses on the wire to encode the property type information. When he shows

us the protocol design (which we were promised last week but didn't have

time to review), we'll see what his current plans are for that

representation.

For network data well defined types should be supported and known by any

code that accesses or provides network available data.

I think Jeff is offering us an API that is a little too abstracted from

the network transport layer, and that's why we've been complaining.

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.

Jeff, you seems to be extremely reluctant to allow this internal

implementation detail to be propagated out to the CA API. Can you

explain why we should have to solve the same problem (the encoding of

the on-the-wire type information) in more than one place? I realize

that it is not hard to write a dataSurveyor to discover and encode the

type of a property using data access, but as far as I can see you

already have to do something like this yourself inside the library in

order to generate the data you put on the wire when you're describing a

client's subscription catalog. Isn't it much better to have one

implementation and one enum/set of integer constants defined centrally

than for everyone who wants one to have to invent their own?

And you will make the user do the following!!!

Actually I think Jeff's design and use of templates here is pretty

ingenious, but they're not really quite as useful in real life as he

makes out.

Suppose I have a position class which has properties X, Y and Z. In my

property catalog for this class, I might want to provide an additional

derived property ORIGIN_DISTANCE. Since this property is derived from

the others and not writable, I can't use the same find() and traverse()

functions for a Manipulator that I do for a Viewer, so I can't use his

template static member function approach and instead have to write two

separate versions of each. I also have no idea whether to reveal three

or four properties to a Surveyor, because I don't know whether the

client is going to read or write my properties.

I still support the use of the data access approach, but it doesn't do

everything we need yet.

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System