RE: Channel Access Client Interface

["Dalesio, Leo `Bob`" <dalesio@slac.stanford.edu>]

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