Rationalise logic of synchronisation between transport, attribute and handler #154
Description
The current synchronisation of values between an attribute, its handler and its representation in the transport layer is incorrect and the methods are named inconsistently.
AttrW.update_display... should be moved to AttrRW - there is no value to update from the Attribute for an AttrW
This WIP diagram describes the logic: https://link.excalidraw.com/l/7igwo1LrqWY/9ogO8dgeY46
Currently these names are quite confusing. We would like to use the following terminology:
- AttributeIO pulls value from the device and pushes it into Attribute -> update
- Transport receives values from user and pushes it into Attribute -> put
- Attribute value is put and needs to push value to device -> send
- Attribute is set internally (or from another transport) and needs to push the value to the transports -> publish
Some thought needs to be put into the various callbacks that can be registered to be called when values change, whether they need to exist, and what they should be called. Potentially terminology of on_put_callbacks, on_update_callbacks and publish_callbacks callbacks would be useful, because publish is generally called when something happens in the Controller internally, rather than when a value is pushed into the Attribute. These would be used for example by the EpicsCATransport to request a demand PV is updated with a new value, but without it causing a process which then sends the value back into the Attribute, i.e. it would register record.set(..., process=False).
Acceptance Criteria
- It is possible to explain the different methods and callback types