Re: Network Accessable Types

[Ralph Lange <Ralph.Lange@bessy.de>]

> 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