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: "Jeff Hill" <[email protected]>, "Bob Dalesio" <[email protected]>, <[email protected]>
Date: Mon, 8 Aug 2005 14:38:02 -0700
If we do support a limited range of types and 32 bit floats are what is supported - when 64 bit ones arrive, isn't it a simple matter to add them?
Bob 

-----Original Message-----
From: Jeff Hill [mailto:[email protected]] 
Sent: Monday, August 08, 2005 1:50 PM
To: 'Bob Dalesio'; [email protected]
Subject: RE: Channel Access Client Interface


Hi Bob,

> ADO handles all conversions

First, ADO is probably a misleading label (presuming this stands for abstract data object). IMHO a better name (thanks Ralph) for the functionality is DA (Data Access) - better labeling it is an interface - an accessor interface. There *is* an associated library of conversion and indexing functions. There *isn't* an implantation of storage - an object.
GDD was an ADO. DA isn't. 

Concerning DA's interface with the user:
----------------------------------------

1) DA will tell the user what the server's native type is {boolean, signedInteger, unsignedInteger, enumerated, real, time, string, array, container}, and what the native type size is in bytes.

2) DA will allow the client side user to select the largest practical size of a particular type, and tell the user if a range error occurs when converting the server's type to the type of the client side user. I believe that this is the model employed by many clients today (except that there is no range checking).

3) DA will allow the user to select a size locked type, and tell the user if a range error occurs when converting the server's type to the type of the client side user.

4) DA will allow the user to select the exact same type used by the server or else the largest available size of that same type, and tell the user if a range error occurs when converting the server's type to the type of the client side user.

This appears, at the interface level (presumably that is what we are designing here), to allow both camp's positions with the only exception possibly being that the above *does* allow for 64 bit types to be gradually introduced. 

The other camp appears to be advocating that 64 bit types are dangerous, and should not be allowed. I can predict that initially no one will consider 64 bits servers to be important, then there will be a transition period where there will be a mixture of both (64 bit servers are essential in certain select situations and 64 bit workstations are ubiquitous), and finally we will see a period where 32 bit servers are rare in the mainstream but possibly common in embedded systems.

> In the first place - the ADO is big and handles a lot. In the second
place,
> it is small and does not support everything.

The biggest job of DA is to map between heterogeneous containers of properties whose content is indexed by traverse and find at compile time, but otherwise not known at compile time. I presume that both camps agree that this is a requirement for implementation of the server's event queue.
The portable server uses GDD for this purpose at this time. See previous papers concerning the lack of popularity of GDD with users when using it implement a service. 

Furthermore, DA must have a conversion matrix, but this is already necessary in the existing system. DA's conversion matrix is better because it range checks before converting.

> Our clients will be about 70% JAVA, and 30% C. How much work is 
> required to get the functionality in the first option into all of these platforms?
> How much is it in the second options?

Yes, for funded future clients this Java predominated ratio might prove to be accurate, but for IOC's C/C++ is essential and we will not have a system if the C/C++ code isn't running - unless of course we were to code IOC core in Java. 

IMHO there is no "voodoo C++ templates" in DA which can't be implemented in other languages. The most important issue is making certain that the interface is correct. Since a functionally equivalent interface can be expressed in the different source languages then I don't see a problem.
Sites w/o unlimited money will probably just choose to wrap the C/C++ implementation with the target languages interface - the predominating approach in the past. Perhaps a Java JNI version (a C/C++ implementation
wrapper) can bridge the gap until a native version is produced? We *will* of course provide backwards compatibility for existing Java CA client interfaces. That is how we have solved such problems in the past. It may be difficult to get the next generation clients funded if they don't initially use backwards compatible interfaces.

The template approach to code development makes the library source code smaller however there are many other reasonable approaches including code that generates source code as was done with the implementation of GDD and its predecessor. Given that Java now has templates I assume that we can start there.

> Where is the example codes that implement the various client functions 
> with the proposed libraries?

Needless to say, I can't give you an implementation at this time. I did present an example client code at the last meeting?

> Where is the protocol that was going to be placed on the wiki?

I do have such a document in rough form, but I am still working on it. I did try to present this at the last meeting, but it was eliminated form the agenda. I will put this up on the wiki ASAP.

Jeff

> -----Original Message-----
> From: Bob Dalesio [mailto:[email protected]]
> Sent: Monday, August 08, 2005 1:02 PM
> To: [email protected]
> Subject: Channel Access Client Interface
> 
> My understanding is that we are stuck at this place:
> 
> One position:
>     We support all data types native to the machine on which the 
> client is run. The ADO handles all conversions, gives native type for 
> each channel connected, gives sizeof infromation for allocating 
> storage, and returns the value in that type of variable - where the 
> space is provided by the user.
> 
> The other position:
>     We support a limited number of types that support all of the data 
> that we need to support. The server puts the data into one of these 
> limited
set.
> Otherwise, it is the same as above.
> 
> The difference in the two, is that the ADO handles many different 
> types in the first position and in the second position the server has 
> to put data into one of the limited set and the ADO only handles the limited set.
> 
> Is this right?
> 
> 
> In the first place - the ADO is big and handles a lot. In the second
place,
> it is small and does not support everything.
> 
> 
> 
> Our clients will be about 70% JAVA, and 30% C. How much work is 
> required to get the functionality in the first option into all of 
> these platforms? How much is it in the second options?
> 
> Where is the example codes that implement the various client functions 
> with the proposed libraries?
> Where is the protocol that was going to be placed on the wiki?
> 
> Thanks,
> Bob




Replies:
RE: Channel Access Client Interface Jeff Hill

Navigate by Date:
Prev: RE: Channel Access Client Interface Jeff Hill
Next: RE: Channel Access Client Interface Jeff Hill
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 Marty Kraimer
Next: RE: Channel Access Client Interface Jeff Hill
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 ·