Add RFC: Move to MVC

[tytan652]

RFC 53: Move to MVC

Summary

• Apply the MVC pattern
• Global config, profile and scene collections are represented by their own object
• Frontend API functions related to config file are replaced

Motivation and Context

The actual code is almost a chimera of software architectural patterns, applying the MVC pattern will allow to untangle the code and make it more clear.

Note, I use mermaid-js diagram so use the link to have them rendered.

Link to RFC

[PatTheMav]

This will obviously be a big undertaking, my biggest issue is that we have so many moving parts in OBS Studio, that I'd first try to understand what part should actually be the central "controller" or if there should be a central controller to begin with.

The questions that pop up in my mind around that are:

• Is libobs the central source of truth?
• Should recording, streaming, buffering, virtual camera output, be independent controllers, as each can have states that are independent of the others - hence would there be multiple sources of truth, one for each?
• Should the UI itself use the frontend-api? This would allow a strong decoupling from libobs and thus force UI code to be self-contained and only concern itself with representing states reported by the frontend api into UI states
• This would make the frontend-api into the de-facto controller for the UI, but not for the activities listed above
• This would also force libobs to not rely on the UI "magically" making it work (i.e. loading runtime libraries would need to be done by libobs, not by the UI)
• In turn this has the potential to make OBS capable to work headless, as the presentation of data and states could be handled and interacted with by UI, a Websocket-based implementation, a service, a command-line interface, because the core functionality does not rely on important things being done by the UI. The UIs decide how to present the data and convert user input into API calls, but the API itself only accepts "generic" interaction

So following those ideas, there could be a "Stream Controller" that manages the state and data of streaming functionality. It receives data provided by the "Frontend Controller" which provides APIs for implementations (OBS Studio being just one such implementation), providing frontend events that implementations need to subscribe to, etc.

This leads to more interesting questions: Should the UI be aware that there is a Stream Controller? Or should it only be aware that the Frontend Controller allows you to create/update/remove streaming setups (that can be started/stopped/paused/whatever), with it taking care of implementing the Stream Controller. It would have the benefit of allowing internal changes made to each controller without it cascading into the rest of the architecture.

Another question is how to handle configurations: Are configurations a UI concern or a libobs concern? I would argue that libobs should work runtime-only and that configurations are handled on the UI layer (which includes profiles and scene setups), so the program or a service would read and parse configurations, create configuration objects from them, and configure the controllers accordingly (possibly via the frontend controller). But plugins complicate this idea: Plugin properties are required by libobs, but their configuration needs to be translated/exposed to the UI somehow.

There are more areas of blurred lines: "Studio Mode" allows you to see the current composition used for the program as well as a preview composition for interaction in the UI, so for that to work libobs needs to be aware of this thing to exist, even though it's purely a concern of how people interact with their program composition. In that case the idea of there being a preview and a program needs to be baked into libobs and the respective controller (which leads to the question of whether program and preview need to be handled by the same object or should have independent states).

But if both are independent "compositions" (which could fix the issue of some sources being manipulated in preview actually affecting the program), the "Stream Controller" would need to know which composition is "the one" that is supposed to go out or will the compositor need to know which composition is the "program"