nrkno / sofie-core

Sofie Core: A Part of the Sofie TV Studio Automation System
https://github.com/nrkno/Sofie-TV-automation/
MIT License
125 stars 38 forks source link

RFC: Changes and addition to (meta)data properties (SOFIE-2797) #1074

Closed ianshade closed 8 months ago

ianshade commented 10 months ago

Background

This RFC is being opened on behalf of TV 2 Norge.

With the adoption of the Live Status Gateway, which allows external systems to get an overview of the state of the Playlist and its contents, a need arose to expose ancillary information about Segments, Parts, Pieces, AdLib Pieces and AdLib Actions beyond what the data model of Sofie covers. Some documents currently feature a metaData field, which was proposed to be exposed by the Live Status Gateway in https://github.com/nrkno/sofie-core/pull/1059, however this property is commonly used to store blueprint-centric information meant to be primarily used by blueprint methods. AdLib Actions currently only feature the userData property, that the executeAction blueprint method can make use of. In many cases it contains lots of data that would be completely irrelevant for an external system. Some information can be already exposed using the tags, but being an array of strings, they are not suitable for more advanced use cases where a properly structured object would be much easier to process.

Proposal

We're proposing the following properties to be allowed to be set by the blueprints on the documents representing Rundowns, Segments, Parts, Pieces, AdLib Pieces and Adlib Actions:

Additionally, Adlib Actions would still have the existing userData property, defined as the public-facing, editable data that can be supplied (overridden) by the external systems when executing the action, optionally described by schema (https://github.com/nrkno/sofie-core/pull/1005) allowing for GUI auto-generation.

Status

This is an RFC - Request for comments (see our Contribution guidelines ).

Followed upon by PR: https://github.com/nrkno/sofie-core/pull/1077

jstarpl commented 9 months ago

Hello!

Thank you for opening this RFC! If you haven’t already, please give our contribution guidelines a read.

We will reach out to you to schedule an initial discussion regarding this (more details to follow).

jstarpl commented 9 months ago

We have no objections to this change in principle, and agree with the objective, so we feel like setting up a whole workshop and discussion is unnecessary.

Our only feedback is that we feel that metaData and blueprintsData still doesn't immediately convey the public/private nature. Arguably, the current metaData field is often used for stuff that's not meta-data, if going by the dictionary definition. Therefore, we would propose doing the following:

ianshade commented 9 months ago

@jstarpl Would you accept the renaming of the existing metaData to privateData to be a breaking change, or should metaData stay and be marked deprecated? Edit: I went with deprecation for now (in the draft PR).

jstarpl commented 9 months ago

@jstarpl Would you accept the renaming of the existing metaData to privateData to be a breaking change, or should metaData stay and be marked deprecated? Edit: I went with deprecation for now (in the draft PR).

Sorry for taking so long to respond. We had a chat in the team, and we think it would be better if we just drop metaData. Since we treat every bluprints-integration as breaking, it seems to make more sense to drop it immediately so that there is no risk of having some metaData and some privateData at the same time, leading to hard to debug bugs.

ianshade commented 8 months ago

https://github.com/nrkno/sofie-core/pull/1077 was merged to release51