search

AMWA-TV / is-13

AMWA IS-13 NMOS Annotation Specification [Work In Progress]
https://specs.amwa.tv/is-13
Apache License 2.0
1 stars 1 forks source link

Add section around change persistance #6

Closed cristian-recoseanu closed 1 year ago

cristian-recoseanu commented 1 year ago

We need a section which describes the requirements around persistance of changes.

I think nodes MUST or SHOULD persist changes issued through this API across reboots but these may be lost if a node goes through a factory reset workflow. Also need to discuss if these changes persist after firmware updates (I personally think yes).

garethsb commented 1 year ago

Definitely! Compare language around reboots, etc. in JT-NM TR-1001-1, which might inspire us...

Media Nodes shall expose unique, immutable, and consistent UUIDs in the IS-04 registry over the life of the product, including consistency over reboots, power cycles, and software upgrades

Note: Typical behavior of professional media equipment is to store current operating settings in a non-volatile manner, and to restore those settings after loss-of-power, so that a whole system can re-start quickly after an outage. In the case of Media Nodes in a networked environment, it is important to distinguish between a device re-starting within the same system environment (such as a reset of one device) and the case of a device being moved from one system environment to another (such as a rental camera at a new job). The situation is made harder by a third case – equipment which has been stored (perhaps in a spares closet) for a long period of time such that its settings are outdated, and then is re-introduced to the environment

cristian-recoseanu commented 1 year ago

Discussion during the meeting: More nuance to be discussed with completely dynamic nodes where UUIDs of resources can change quite rapidly making this API less useful for some of the proposed workflows because the UUIDs are the anchors for all the changes.

cristian-recoseanu commented 1 year ago

Discussion during the meeting: Some larger data fields like descriptions might pose issues to smaller devices in terms of persistance. Should we allow partial elements of a request to succeed? (e.g. fail a very long description but allow the tags to go through?).

garethsb commented 1 year ago

Discussion during the meeting: More nuance to be discussed with completely dynamic nodes where UUIDs of resources can change quite rapidly making this API less useful for some of the proposed workflows because the UUIDs are the anchors for all the changes.

Yes... except that resource IDs can't change, resources can only be deleted and created, and the Controller can get notification of these new resources via the Query API mechanisms.

If that's definitely not enough, we'd potentially benefit from an API that allows the client to specify label/description/tags for all current and future resources, or resources of a particular type, created by this Node (perhaps if not overridden on a per resource basis).

peterbrightwell commented 1 year ago

2023-05-04: confirmed need for guidance on persistence and rejecting requests that can't be persisted. Persistence should be tied to the lifecycle of the relevant resource (see also comment on dynamic resources in #9)

garethsb commented 1 year ago

rejecting requests that can't be persisted

Are we saying that a device MUST (or SHOULD?) reject changes that it cannot persist over reboots? (Or even "over reboots, power cycles, and software upgrades" as per JT-NM TR-1001-1 requirements for persistent resource IDs.)

peterbrightwell commented 1 year ago

2023-05-18: see notes on #16. @cristian-recoseanu to write a more accurate issue.