Comment 2 for bug 541254

After I patched the example server so that it would not change the
native type of the PV to double I can now use it to demostrate that
the following correct sequence of events occurs when a client requests
a PV with native type aitEnum be converted to external client type
DBR_STRING.

o The CA server creates the destination GDD with proper application type
and with primitive type wildcarded.
o CA server calls the server tool's read VF with this GDD as the destination
o Server tool copies into this GDD setting it to the native type (in
this case aitEnum)
o The CA server calls aitConvert() to convert this GDD to a DBR_STRING
using an enumeration sting table that it has cached (this cache is
of course initialized by calling the server tool's read VF).

This is exactly how Jim and I originially intended for eneumerated types
to be implemented.

Its true that gdd::smartCopy() provides a nill enumeration string table
to aitConvert(), but this should presumably be a non-issue for the GW
since it should be preserving the native type (in this case aitEnum)
for all of its internal PV.

Since the GW should not be storing a PV with corresponding native
type in the IOC is enumerated in type string then smartCOPY shouldnt
need to have an enumerated string table argument.

If the GW were to allow the primitive type of its GDD storage for a
PV that is enumerated to stray off of aitEnum then trouble is probably
guaranteed.

That issue probably needs to be pursued in the GW.

The problem with storing a reference to gddEnumStringTable in aitEnum16
(in the GDD) is that you either have to store a copy or a reference. If
you store a copy there is too much overhead. If you store a reference
there are too many problems with a GDD ending up using a dangling reference
to a string table that no longer exists. To avoid a very complex interface
for users we decided to go with a solution caching the string table in
the server.

edited on: 2005-10-27 18:25