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
- Replies:
- Re: Channel Access Client Interface Kay-Uwe Kasemir
- References:
- Channel Access Client Interface Bob Dalesio
- Re: Channel Access Client Interface Kay-Uwe Kasemir
- Navigate by Date:
- Prev:
RE: Channel Access Client Interface Jeff Hill
- Next:
Re: Channel Access Client Interface Marty Kraimer
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Channel Access Client Interface Kay-Uwe Kasemir
- Next:
Re: Channel Access Client Interface Kay-Uwe Kasemir
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|