RFC: Configurable error messages from Package Manager

[Julusian]

About Me

This RFC is posted on behalf of the BBC.

Use Case

Currently, the error messages from the Package Manager are quite limited and fail to provide useful information in setups where multiple playout servers are tied to a single timeline layer, such as studio screens.

For example, here’s a case where the current error messages fall short:

Proposal

Proposed solution allows error messages from Package Manager to be configurable with the goal to be able to show more helpful error messages to a user.

An example of a error message we would like to see is something like this:
MY_CLIP_NAME cannot be found on Caspar 01

This provides more helpful information as it details both the clip name and playout device, making troubleshooting easier.

Some possible solutions to this are:

Config fields

Add config fields to choose which messages are used. Perhaps to:

• Show clip names
• Include playout device name
• More might be needed, we haven't studied all the messages to figure out what they should become.

I suspect it will become very hard and messy to do this, to support every combination of functionality, especially when other broadcasters want something slightly different.

Blueprint driven

The blueprints could optionally provide something like Record<PackageStatusMessage, string> for any messages they want to override. Which core could utilise these instead of the default messages.

• Sofie can safely throw more arguments into the translations interpolator, if they aren't used they don't get shown.
• These notifications are generated in a publication for a specific bucket/rundown, so could safely use one of the blueprints to achieve this.
• This then keeps the new messages as part of the blueprint code, minimising complexity in the ui and implementation, while still giving flexibility for the messages (while retaining the ability to translate them for multi-language scenarios)

I think this is a better approach, it allows for granular overriding and gives more customisability.

For both solutions, is there a way we can get a 'nice' name for the playout device that is missing the clip?
Maybe this should be using the container name instead? The code knows what container it is missing from.

Process

The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.

• RFC created
• Sofie Team has evaluated the RFC
• A workshop has been planned
• RFC has been discussed in a workshop
• A conclusion has been reached, see comments in thread