Closed ianshade closed 8 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).
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:
metaData
to privateData
- and have that as the Blueprints-controlled private data blobpublicData
and have that be exposed in the Live Status Gateway.@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 Would you accept the renaming of the existing
metaData
toprivateData
to be a breaking change, or shouldmetaData
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.
https://github.com/nrkno/sofie-core/pull/1077 was merged to release51
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 theuserData
property, that theexecuteAction
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 thetags
, 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:
metaData
- the public-facing metadata that has some meaning to the outside world, and the external systems will have access to, through means like the Live Status Gateway's topicsblueprintsData
- data available only to the blueprints, where the blueprints can store any internal information for their own access later, e.g. to be used in methods likeexecuteAction
andgetEndStateForPart
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