With Channel Access, clients know beforehand if a channel is read-only or writable.
A GUI can indicate read-only access via for example a changed cursor or a "disabled" widget.
CA sends updates when the write access changes on a connected channel.
With PVA, we current only get errors when trying to write a read-only channel.
The protocol https://github.com/epics-base/pvAccessCPP/wiki/Protocol-Messages contains ideas for an accessRights mask sent during channel creation as well as a CMD_ACL_CHANGE (0x06) message for updates, but none of these have been implemented.
We understand that the PVA scenario is more complex than CA. While CA assigns one read/write mode to the whole channel, a PVA table might allow access to certain columns, and a custom PVA structure may only allow access to selected elements.
Still, having no read/write access information is clearly a step back from CA. We do need to support the basic use case of ai, bi, calc, ... records on IOCs accessed via QSRV. GUIs that use PVA should have the same basic behavior as CA, indicating read-only access in the same way.
The proposal is thus to add an overall bit to the createChannelResponse that indicates if there is (at least some) write access or if the channel is completely read-only. In addition, a protocol message needs to be added that indicates changes in write access, where again a single bit may suffice.
Because of the more complex nature of PVA data, a channel that indicates at least some write access might still return a permission error when writing certain data to certain fields. The goal is to support GUIs, allowing for the same behavior as CA, where the read/write access basically informs about the "value" of the channel.
Details will need to be discussed. Ideally, the changes would be backwards compatible, using bits in existing protocol messages that older clients will simply ignore.
This issue is filed with pvAccessCPP because it documents the protocol in the associated wiki. We may well first implement this with PVXS (C++) and core-pva (Java), but the protocol changes will be documented in https://github.com/epics-base/pvAccessCPP/wiki/protocol
With Channel Access, clients know beforehand if a channel is read-only or writable. A GUI can indicate read-only access via for example a changed cursor or a "disabled" widget. CA sends updates when the write access changes on a connected channel.
With PVA, we current only get errors when trying to write a read-only channel. The protocol https://github.com/epics-base/pvAccessCPP/wiki/Protocol-Messages contains ideas for an
accessRightsmask sent during channel creation as well as aCMD_ACL_CHANGE (0x06)message for updates, but none of these have been implemented.We understand that the PVA scenario is more complex than CA. While CA assigns one read/write mode to the whole channel, a PVA table might allow access to certain columns, and a custom PVA structure may only allow access to selected elements.
Still, having no read/write access information is clearly a step back from CA. We do need to support the basic use case of ai, bi, calc, ... records on IOCs accessed via QSRV. GUIs that use PVA should have the same basic behavior as CA, indicating read-only access in the same way.
The proposal is thus to add an overall bit to the
createChannelResponsethat indicates if there is (at least some) write access or if the channel is completely read-only. In addition, a protocol message needs to be added that indicates changes in write access, where again a single bit may suffice. Because of the more complex nature of PVA data, a channel that indicates at least some write access might still return a permission error when writing certain data to certain fields. The goal is to support GUIs, allowing for the same behavior as CA, where the read/write access basically informs about the "value" of the channel.Details will need to be discussed. Ideally, the changes would be backwards compatible, using bits in existing protocol messages that older clients will simply ignore.
This issue is filed with pvAccessCPP because it documents the protocol in the associated wiki. We may well first implement this with PVXS (C++) and core-pva (Java), but the protocol changes will be documented in https://github.com/epics-base/pvAccessCPP/wiki/protocol