Extend CA library to fully support dynamic array set and get

[simondelabici]

Hi Alex and Simon

Just to ensure that we are all on the same page I am setting up this issue up so that we can capture the discussion Alex and I are currently having on how best to support dynamic array get and set operations in the CA library. I will write below what I understand the current status of the library to be, some questions that I have, and some suggestions as to how we move the library forward.

Please correct my mistakes, add information, and/or raise questions where you have a different view and/or understanding:

CA Library Current Status (as of release 1.3.2)

1. The PSI CA client library claims to support the latest version of the CA protocol. Currently this is CA_4.13, which was released in 2010. The specification is here.

2. Since V4.13 the protocol supports reading and writing arrays that are smaller than the channel's so-called native element count (an immutable value which is determined on the IOC at init time). See particularly this part of the spec.

3. Although the PSI CA lib provides support for variable length arrays in its protocol implementation, the API offered to library users does NOT currently provide support for variable length read operations.

4. I believe the library does currently support variable length write operations. This is achieved implicitly by setting the appropriate array size.

5. To be compliant with the implicit promise offered by the 4.13 protocol spec it seems to me the CA library needs to offer API methods to support:

   • read/write of native element count. (ie default old behaviour).
   • read/write of user specified number of elements. (ie support for "new" behaviour).

6. I think the library should now be extended to support variable length read operations. There are two interfaces to consider: the Java API Method Interface and the Annotation Interface.

7. Java API Method Interface: probably we just need to provide additional methods (for async and non-async flavours) where the user explicitly states the number of elements to read.

8. Annotation Interface: presumably we need to offer the same support in the CA library interface as that offered by JCAE. Do I understand that JCAE already supports dynamic array put/get ? Can we use the same interface for CA ?

Over to you guys for comments / suggestions / questions...

Thanks and greetings
Simon

[alexgobbo]

I don't think we should change the annotation interface. There we define channel aspects that are static, and we may want to change the elements to read dynamically. I think it is enough for the channel to have a "elementsToRead" property that, if specified, forces the size of array to be returned. The default is the current behaviour: size is given by the protocol or channel type. There is also the possibility to force the native element count regardless the
protocol (which solves the bug on the IOC running on my Mac).

[simondelabici]

For reference the JCAE documentation can be found here.

[simondelabici]

Alex wrote:

"I don't think we should change the annotation interface. "

Fine by me. Because I haven't used this library I thought perhaps this feature was already supported in the existing annotation interface.

(Actually, I hadn't realised until I looked at the link above that JCAE provides an interface that offers methods as well as annotations).

Alex wrote:
"I think it is enough for the channel to have a "elementsToRead" property that, if specified, forces the size of array to be returned."

I can see this will work. I am not currently sure how well adding a special property on the channel fits with the current CA API paradigm. Maybe that is more consistent with the JCAE approach ? Maybe Simon (who helped specify the existing CA interface) knows more ?

I guess, the alternative would be to avoid introducing extra state into the library by adding an extra method where the user explicitly requests the number of desired elements. From a user's perspective would that also give you what you need ?

Anyway, we can continue this discussion if you send the pull request.