EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Channel Access Client Interface
From: "Dalesio, Leo `Bob`" <[email protected]>
To: "EPICS Core Talk" <[email protected]>
Date: Tue, 9 Aug 2005 05:48:03 -0700
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:[email protected]] 
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



Replies:
Re: Channel Access Client Interface Marty Kraimer
Re: Channel Access Client Interface Ralph Lange

Navigate by Date:
Prev: Re: Channel Access Client Interface Marty Kraimer
Next: Re: Channel Access Client Interface Kay-Uwe Kasemir
Index: 2002  2003  2004  <20052006  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 Jeff Hill
Next: Re: Channel Access Client Interface Marty Kraimer
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·