Re: dataAccess V4 Ca client propertyId questions

[Ralph Lange <Ralph.Lange@bessy.de>]

Kay-Uwe Kasemir wrote:

> Yes, Jeff proposes a channel::createAllPropertiesReadRequest.
> Does that cover your idea for a simply 'probe'- type application?
>
>      createAllPropertiesReadRequest
>      ...
>      foreach p ( da->getProperties() )
>      {
>          display da->getType(p), da->getAsString(p)
>      }
>
> ... or would you also like to see a request that only
> gets the properties and types, without fetching any actual values?

Yes, we need that request!
(And I think we already agreed on it at the SLAC meeting, but everyone 
seems to have different memories of that meeting to an extent that I 
start to believe we attended different parallel meetings. Or the same 
meeting in parallel worlds.)

Let me give two reasons why:

1. Access Rights
The Viewer (read) traverse() will only show properties that are readable.
The Manipulator (write) traverse() will only show properties that are 
writable.
Both could be limited down to very few by Access Security or a similar 
mechanism.
If a probe-type client wants to show all properties and the access 
rights for each of them, there has to be another traverse() that shows 
*all* properties, together with the access rights for each.

2. Primitive Types
Data Access hides the native type of the data by providing templated 
functions for each of the interface types that do all necessary 
conversions. The only way for a client to find out about the native type 
of data is to provide a bunch of Viewers (one for each interface type) 
and see which one gets called. (If for a particular non-C++ dataAccess 
implementation the interface type is different from the internal 
primitive type, even this method will only get a hint.)
So the third traverse() should also yield the native primitive type for 
a property (one out of a list of well-known, machine, architecture, 
language independent and size-fixed primitive types).

Ralph