Experimental Physics and
Industrial Control System

Nikolay,

For the write implementation what you have will work but you are allowing the client to change the GDD primitive type and application type structure of your service’s representation – which may or may not be appropriate in your situation. You end up with an un-typed service which could cause less predictable behavior. The client could for example change, using one write, a double value surrounded by lots of meta data into the string value “off” with no metadata for example.

For your read implementation the primary concern might be that the service wouldn’t be looking at some of the details of the read request from the client. In particular, the destination GDD comes preformatted with all of the application types that the client is fetching (i.e. all of the GDD application types in a CA DBR_XXXX – say DBR_GRAPHIC_DOUBLE), but your code snippet is substituting instead what the service is storing. Maybe this is ok as long as a superset of all of the application types is always provided (where the superset is modal depending on the DBR_XXXX data model for the value type of string, float, or enum). The client’s request would be rejected for example if the destination value has primitive type double and the substituted value is a string with value “off”. What you have suggested might be ok as long as you don’t mind leaving the error checking to the server. The server does do the necessary primitive type conversion checking of the response. If any of the application types are missing for the clients DBR_XXX type then the client’s read request is rejected.

The code in base/src/makeBaseApp/templates/caServerApp/exPV.cc shows another way to implement a read using a dispatch table for each of the applications types. I don’t claim that it’s the proper way to structure a service, but perhaps it can provide some contrast.

The GDD library also as I recall supports GDD container to GDD container assignment which would be another way to implement the read.

Jeff