Should we reevaluate how we handle our tally objects on the backend of Tally Arbiter?

[JTF4]

I've been doing a lot of thinking on how to streamline and make the back end processing for TallyArbiter better.

On of the things that come to mind is how we process and transport tally. Currently we are getting tally and converting it to a TSL3 object. Depending on the source type, this can leave a lot of extra data and information behind as the TSL3 object doesn't contain any space for that extra data.

I'm wondering if we should consider switching to a JSON object that contains all of the information we need. This would allow us to store more information about that tally object like it's original source, the name that the switcher is reporting, the exact time the update arrived at TA, the address that it's coming from, and a simplified way of handling tally using an object like isPreview, and isProgram. This would also allow us to in the future simplify the creation and export of EDLs from TA.

I know that this would be a large shift in how we process things, but what are your thoughts on this?

I think it would ultimately allow us to be more flexible in the future.

[josephdadams]

Love this idea. It would be great to store as much original data from the source type before considering it processed. Especially when trying to fully support an extendible amount of busses beyond just pvw/pgm.