Assign NTEnum by string?

[mdavidsaver]

After epics-base/p4p#27 I am convinced that forcing clients to handle the choices list during Puts is a recipe for bugs and races. I'm inclined to start changing this by adding an additional field to the enum_t sub-struct for QSRV.

This would give conceptual equivalence to the handling of DBR_ENUM in CA.

pv:name epics:nt/NTEnum:1.0 
    enum_t value
        int index 0
        string[] choices ["Zero", "One"]
        string choice "Zero"             # <-- new

The semantics would be that during a Get or Monitor, QSRV will ensure that both value.index and value.choice remain consistent. With the case of out of range index being undefined (eg. maybe "Illegal Value" as with mbboRecord).

During a Put operation, a client may provide index and/or choice string. The value.index only case is already handled. The value.choice case would be handled by referring to the current choices list known to the server. If both are provided (eg. by mistakenly sending the whole sub-struct), then value.choice would be ignored in favor of value.index. This would give consistent (mis)behavior for clients which don't know about value.choice.

@shroffk @kasemir @sveseli @hhslepicka Would anyone else maintaining PVA client apps. care to comment?

[kasemir]

What about the basic pvput command line case?
Does it need to write an NTEnum int value.index?

For channel access writing to an enum field, it's OK to write a plain number or string. The server maps either one to the index or searches for a matching label.

How about making the PVA implementation (QSRV) similar, meaning: You can write an NTEnum int value.index. But you can also just write a non-NT-type struct with int value or string value.