Re: Channel Access Client Interface

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

Almost. But not really.

The _expression_ "server-side" types has double quotes, because, when seen from the client, these types are returned for the native type of the data, which resides on the server.
The server itself, on the other hand, uses DataAccess and is programmed in a certain language. Naturally it will use the types of that language to store the data. DataAccess will convert from the local language types (par. 2) to and from the fixed types (par. 1) on both the server and the client side.

So: The distinction is not between server and client, but between DataAccess space (platform and language independent, used in CA) and user space (local, language specific, used in server and client apps).
We will have one fixed, language and machine independent set and multiple language dependent sets that DataAccess will have to support for different languages.

The first step is to define the independent set. (This is what you ask Marty for.)
The second step is to have DataAccess in its C++ (Java) implementation support C++ (Java) types that are resonable and needed to hold data for the types in the independent set.

Ralph


Dalesio, Leo `Bob` wrote:

OK - so we have a set on the servers and a set on the clients. As the first set comes from the database, can Marty list what the database fields will be supporting? Then Kay/Doug can list what they would want to see on the client side as possibilities.
Bob 

-----Original Message-----
From: Ralph Lange [mailto:Ralph.Lange@bessy.de] 
Sent: Tuesday, August 09, 2005 12:57 AM
To: EPICS Core Talk
Subject: Re: Channel Access Client Interface

Kay-Uwe Kasemir wrote:

  

Hi:

I think Ralph's recent answer with regard to the gateway already shows 
that we can _not_ support all data types native to the machine on 
which the client is run.

We have to agree on a limited set of types because the gateway must 
understand all types in order to compare the values against deadbands 
etc.
    

I'm happy to repeat once more:

There are _two_ type spaces [or whatever term is appropriate] connected to this issue, which are _separate_.

1. One type space contains the fixed set of native "server-side" types that Data Access is going to support when transporting stuff - across language and machine borders. We have to define this type space, together with a clever implementation of a type designator, that should be comprehensive and easy-to-use. (Kay's further discussion is about this type space.)

2. The other type space contains some (probably a subset) of the Data Access implementation language's basic types. These are the types that a user application will use to store the data, so Data Access will use these types in the interfaces and will convert between the language and platform independent fixed types (last paragraph) to the types of the user's data (this paragraph).

It's not that difficult, is it?

Ralph