Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 8 Aug 2005 14:49:48 -0600

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System