Skip to content

Implementation of IS-13 NMOS Annotation API - #331

Open
garethsb wants to merge 1 commit into
sony:masterfrom
garethsb:rwnode
Open

garethsb wants to merge 1 commit into
sony:masterfrom
garethsb:rwnode

Conversation

@garethsb

Copy link
Copy Markdown
Contributor

⚠️ Ink isn't dry on the IS-13 spec, but here's an implementation.

@garethsb garethsb changed the title Implementation of IS-13 NMOS Read/Write Node API Implementation of IS-13 NMOS Annotation API May 22, 2023
@garethsb

Copy link
Copy Markdown
Contributor Author

Current annotation_patch_merger has three arguments:

  1. const nmos::resource& resource - the IS-04 resource that is being PATCHed
  2. web::json::value& value - contains the annotation properties from that resource, modifiable by the callback
  3. const web::json::value& patch - contains the body of the PATCH request, which is guaranteed valid per the schema

The behaviour is that the callback is expected to update the value with the patch, and then the calling function updates the resource from the updated value.

Passing read-only resource and a writable value ensures that the callback cannot update other properties than label, description and tags, but that it has access to the full resource to determine semantic validity.

However, the implementation is still a bit complicated. The callback might want to proceed to...

  • reject the PATCH request completely if it attempts to change to read-only properties e.g. because the whole resource is read-only (Sources and Flows in dynamic Nodes), or because certain tags are read-only such as BCP-002-02 Asset Distinguishing Information or vendor-specific tags
  • reject the PATCH request completely if the values are unacceptable for this particular resource, such as being too large for persistent storage or not meeting format for particular tag
  • merge the patch
  • apply default values if the PATCH request removed/reset values that cannot be omitted per spec or particular resource
  • reject the PATCH request completely if the final values are unacceptable

@garethsb

Copy link
Copy Markdown
Contributor Author

As @jonathan-r-thorpe suggested, nmos::details::is_read_only_tag is now an overridable predicate, and default values can also be specified declaratively. This is demonstrated by nmos-cpp-node/node_implementation.cpp for the Node and Device tags specified via config.json node_tags and device_tags.

@garethsb
garethsb force-pushed the rwnode branch 2 times, most recently from c92ceb1 to b7c2e57 Compare May 23, 2023 13:59
Comment thread Development/nmos/annotation_api.h Outdated
@garethsb

garethsb commented Jul 1, 2024

Copy link
Copy Markdown
Contributor Author

@jonathan-r-thorpe, @lo-simon, I've just attempted to merge master into this rwnode branch, so let's keep an eye on the tests :-)

Implement GET/PATCH of resource label, description and tags on the Node,
with a default merger that treats BCP-002-01/BCP-002-02 tags as read-only.
Advertise the API as an IS-04 Node service and keep schemas aligned with
is-13 v1.0-dev.

Signed-off-by: Gareth Sylvester-Bradley <garethsb@nvidia.com>
@garethsb

Copy link
Copy Markdown
Contributor Author

Rebased onto current master as a single commit and force-pushed garethsb:rwnode.

@garethsb

Copy link
Copy Markdown
Contributor Author

This implementation has been run against the revised IS-13-01 suite in AMWA-TV/nmos-testing#914 (all test_00test_18 passed, with Node/Device BCP-002-02 asset tags and Sender/Receiver BCP-002-01 group hint present).

nmos-cpp CI clones AMWA-TV/nmos-testing master and runs a fixed list of suites, so IS-13-01 cannot be added there until #914 is merged. We'll wire it into CI at that point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant