About Me
This RFC is posted on behalf of the BBC.
Use Case
Blueprints are able to produce user facing notes at various times, but the lifecycle of those notes is inconsistent and unclear.
Some are created by ingest and remain until replaced by re-ingesting the part. Some are created during playout and are cleared by the next similar playout operation. Some are created during playout and exist until the partinstance is reset/deleted.
We have a desire to add some messages to the segment header that should be possible to define during ingest, and update during playout. As a short-term quick solution, we have added this as a new property on the Part, but we feel that this could be another type of the existing notes. This would require addressing the existing note lifecycle issues present for notes, but would give us one system that works better instead of creating a new specific flow to solve this one case.
Proposal
The TLDR is to expand the functionality of the existing notifications to allow notes to override each other, and expand the blueprint api to be able to utilise this.
A rough proposal for the collection is to rework it to contain something like:
type DBNotificationObj = DBNotificationContent | DBNotificationClear
DBNotificationContent → { _id, category, localId, severity, message, relatedTo, created, modified }
DBNotificationClear → { _id, category, localId, cleared: true, relatedTo, created, modified }
The idea here is that we keep the category system like today, but group all Notifications for the segment by localId, so that only one from each localId per part/segment will be provided to the ui. This creates a overriding flow, which can be used to clear/update notes from elsewhere. This grouping will include notes produced during ingest, allowing playout operations to override those defined during ingest.
There is a special ‘clear’ marker document here too, to allow for suppressing a note that is not wanted (while avoiding needing to mutate the original source, to make it safe for playout to suppress an ingest note)
I think some thought is needed on exactly how this overriding/heirarchy will work, perhaps it is simply:
- Playout should always override ingest.
- Playout should only have one note per localId at a time. or the latest modified playout note for a localId is used
We already have a UISegmentPartNote publication used for some server side generation/manipulation of some notes/notifications. This would be expanded/renamed to be the sole way to retrieve these notifications/notes for the ui/lsg.
In the blueprint playout methods, a new clearNote method will be added to be able to create one of the clear markers. The existing notifyUserError and similar methods will need adjusting/renaming to allow for the blueprints to specify the localId of the notification, currently this is an internal detail used for core produced notifications. Perhaps we should have a way of querying the existing notes so that blueprints can discover ones they may wish to suppress?
Finally, we will add a new note level (or display target property?) to be able to direct certain notes to the segment header instead of the notification center.
Optionally, the original plan for this had the idea to remove the notes property off DBPart, and to make ingest write these into the notifications collection instead. I think this will add more unnecessary complexity to manage the shared ownership of the collection, so am leaning towards not doing this. Instead the notes property should be blocked in the publications, so that the ui/lsg doesn’t utilise them directly (the UISegmentPartNote publication should be used instead). I also think keeping notes on DBPart will avoid some potential issues around these notes when the Part and PartInstance differ.
Process
The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.
About Me
This RFC is posted on behalf of the BBC.
Use Case
Blueprints are able to produce user facing notes at various times, but the lifecycle of those notes is inconsistent and unclear.
Some are created by ingest and remain until replaced by re-ingesting the part. Some are created during playout and are cleared by the next similar playout operation. Some are created during playout and exist until the partinstance is reset/deleted.
We have a desire to add some messages to the segment header that should be possible to define during ingest, and update during playout. As a short-term quick solution, we have added this as a new property on the Part, but we feel that this could be another type of the existing notes. This would require addressing the existing note lifecycle issues present for notes, but would give us one system that works better instead of creating a new specific flow to solve this one case.
Proposal
The TLDR is to expand the functionality of the existing notifications to allow notes to override each other, and expand the blueprint api to be able to utilise this.
A rough proposal for the collection is to rework it to contain something like:
The idea here is that we keep the category system like today, but group all Notifications for the segment by localId, so that only one from each localId per part/segment will be provided to the ui. This creates a overriding flow, which can be used to clear/update notes from elsewhere. This grouping will include notes produced during ingest, allowing playout operations to override those defined during ingest.
There is a special ‘clear’ marker document here too, to allow for suppressing a note that is not wanted (while avoiding needing to mutate the original source, to make it safe for playout to suppress an ingest note)
I think some thought is needed on exactly how this overriding/heirarchy will work, perhaps it is simply:
We already have a UISegmentPartNote publication used for some server side generation/manipulation of some notes/notifications. This would be expanded/renamed to be the sole way to retrieve these notifications/notes for the ui/lsg.
In the blueprint playout methods, a new clearNote method will be added to be able to create one of the clear markers. The existing notifyUserError and similar methods will need adjusting/renaming to allow for the blueprints to specify the localId of the notification, currently this is an internal detail used for core produced notifications. Perhaps we should have a way of querying the existing notes so that blueprints can discover ones they may wish to suppress?
Finally, we will add a new note level (or display target property?) to be able to direct certain notes to the segment header instead of the notification center.
Optionally, the original plan for this had the idea to remove the notes property off DBPart, and to make ingest write these into the notifications collection instead. I think this will add more unnecessary complexity to manage the shared ownership of the collection, so am leaning towards not doing this. Instead the notes property should be blocked in the publications, so that the ui/lsg doesn’t utilise them directly (the UISegmentPartNote publication should be used instead). I also think keeping notes on DBPart will avoid some potential issues around these notes when the Part and PartInstance differ.
Process
The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.