Add RFC: Program-neutral Plugin Manager #34
Conversation
|
There are several remaining problems to be solved:
|
|
So I really like the directory structure as proposed, and the plugin metadata format. Some form of that should absolutely be used in a package format for plugins, regardless of how the management or API is implemented in OBS. Additionally, I like that this RFC is at least concerned with a local implementation as it's starting point, rather than what usually ends up being talked about (like repositories and discoverability of plugins in-app, but without actionable steps to actually producing an end product). While I think this doesn't tell the full story of implementing it, it has enough detail for someone to be able to start work, which is good. My worries are a bit more fundamental to the ideas you've presented though. We have no responsibility to alternative frontends, and I don't see what benefit we're supposed to get out of working on an implementation that is a frontend agnostic plugin. Plugins shipping with additional Qt modules would ideally need to report their use of modules so that OBS can make decisions around whether it's compatible. That is entirely a UI concern. The only way that would work is if the API let a frontend tell it dependency versions to check against that only matter for that frontend. Having the management as part of the frontend would make it much simpler, since we can reliably make more assumptions about the environment. Doing it as part of the frontend also results in less work overall, since we can include the logic or checks as part of the existing code path that initializes libobs. This also makes it much easier to do things like prompting the user before libobs loads if we've determined that a plugin is causing problems, like preventing loads, or repeatedly crashing within the last so many launches. I am aware that doing these as frontend changes will mean we need make changes to libobs to support them (such as either setting a module as disabled to prevent it from loading, or providing an alternative obs_load_all_modules function with a callback to let the frontend determine if it wants to load the plugin), but I see no reason to limit ourselves in how we develop anything for the sake of other frontends when that only adds additional blockers and work for us. The whole thing with providers and additional plugin structures seems to only exist to avoid making changes to the frontend or libobs, but that adds a whole lot of complexity that a frontend and libobs change would make much simpler. Why a provider system, when we could add code that runs for all plugins that reads a manifest associated with an installed plugin, and if that includes information about channels or where to find updates, we perform regular update checks (probably through some kind of cached reverse proxy for privacy reasons) and act on behalf of the plugin to update (probably after prompting the user for permission) or present options for switching channels. This also means all loading of plugins occur in the one code path, rather than being split between the frontend and a plugin, so maintenance is much easier. The only benefits that doing things this way seems to present to me, is making sure other frontends get the same benefits of the work (which does not benefit us) and—since it doesn't depend on frontend/libobs changes—we could push this kind of plugin manager to the program separate from an update (which I do not believe is important to us). |
It is correct that OBS Project has no obligation to support Third-Party Front-Ends, however I saw no reason to modify an already implemented design just to spite others. There are also massive benefits to doing it this way, such as detaching the frontend of the plugin manager from the plugin manager itself, allowing it to be updated outside of the OBS Studio update intervals. Plugins would also be able to query for information without requring a link to obs-frontend-api.
Such a modification to libOBS is not needed as obs_open_module already exists. This function is internally called by obs_load_all_modules, which also calls obs_find_modules.
See other RFC about Steam distribution. The provider system would allow us to support Steam Workshop for plugin distribution without much difficulty. |
|
Yes, it is clear that in my cursory glance to remind myself of how the module loading code works that I confused what was internal private functions, and what were public. You are correct that it wouldn't require any libobs changes, and I was mistaken. Regarding what you have said in your response to third-party frontend support, I've been thinking through this for a few days, and I don't see how we're supposed to win here. From what you have said here, and based on what you've said in our Discord server, it seems clear that you've made this RFC submission after having already done at least some—if not most—of the work necessary in implementing the design as described. The point of the RFC process is to discuss the merits of potential implementation details of an idea so that it can inform an actual implementation that gets made later. On an RFC, we should be questioning the design, any assumptions, or general approach to a problem and whether that is of benefit to the project. It is well within scope for us to naturally question things like whether frontend agnosticism is good for this particular kind of feature, and to weigh up the merits against alternatives that would be tied into the frontend. Since you've already implemented and achieved the goals set out in the RFC, and have done so in a frontend agnostic way, you have given yourself the power—whether you intend to wield it or not—to shut down or undercut any meaningful conversation of such things by framing it as us simply looking to spite others. If we determine that it'd be easier to maintain and achieve our goals with a simpler implementation that doesn't introduce new structures and paradigms, and that exists as part of our frontend, then you can say we're spiting the developers of other frontends, because it has now been framed as us rejecting an existing, working, frontend agnostic solution in favor of a brand new solution that would only work for us. If we don't agree with the fundamental design or approach and we reject it because of that, then you could say we're spiting you because you've already put in the work, and we'd be rejecting not just the idea but the work you've done upfront. If we request changes that would make it conform to our preferred design or approach, then you could say we're spiting you because we'd be asking you to redo work you've already completed. You chose to implement a design with no communication with us. You opened up this RFC and titled the PR around being program-neutral, specifically setting up the discussion to be around whether we want a plugin manager which is program-neutral. When I brought up that discussion point, your primary justification was using that existing implementation to defend the design, and framing an alternative implementation proposal as spiteful. This is not how we want to approach RFCs, and having already put in work should never be a reason cited for why something should be a certain way. We're here to discuss designs and ideas on their merits and benefit to the project. We should be looking at the benefits a frontend agnostic implementation could provide us—of which you provide only a couple, and I personally don't see as worth the extra code, maintenance and complexity—but your framing now makes further discussion difficult to handle in good faith. I can only really come to the conclusion that with your entire approach to this RFC, you either fundamentally misunderstand the purpose of the process, or worse, you've intentionally submitted this RFC in bad faith. |
You are correct that I have created this RFC after implementing a "working" prototype, and as you might have read on Discord that prototype also leaves a lot of questions yet to be answered. Excerpts from Discord (also publicly visible if you scroll up in #development):
I am well aware of how RFCs work for OBS Project. I am also aware that I submitted this as a draft and not ready for review, and I hope you are too. This RFC is to date incomplete and based on a barely working prototype, which leaves too many questions open.
As far as I am able to tell from what you've written, your arguments were:
And my counter arguments were:
Partially correct. What I have done is implement something out of thin air, with no planning, design or RFC to back it up at the time. In fact the current "working" prototype leaves so many questions open that it might not even be considered a prototype - all it does is discover plugins in predefined directories, list them and their information, and load them on launch. And yes, I have reduced my contact with the OBS Project team after having been asked to reduce my interaction with it - so I've literally followed your own requests, and am being blamed for it.
The reason for the title including the "Program-neutral" part is because #4 already discusses a plugin manager that is tied to the current frontend. It was included to explicitly set the RFCs apart by their nature, instead of having two nearly identical RFCs. Effectively this RFC only discusses the backend part, not the frontend part.
Please refrain from making further unfounded claims. I have not submitted this RFC in bad faith, quite the opposite actually - otherwise this would have already been fully designed, implemented and released before even considering an RFC. As you can see, none of that has happened. |
|
This seems like a step in the right direction to me. The plugin manager is a complicated component so splitting it into front-end and back-end would allow us to just focus on getting the latter right in this RFC.
I guess I provided more questions than answers, but maybe it'll be useful in some way. I'd really like to see this move forward. If we can get this to a point where an early prototype can be created we can probably also get some progress done on the other RFC. So thanks for writing this RFC up! |
|
I apologize for the lack of updates here, the past few weeks have been very busy. I will most likely split some parts of this into additional RFCs, as this one has grown to a size where it no longer covers just one thing, but many things. |
|
Split the plugin packaging format to #35. |
|
Closing as requested. |
Description
Proposes a program-neutral plugin manager which can be created without requiring a new version of libOBS through the use of libOBS procedure handlers. This plugin manager does not address the user interface or URL integration portion, which are separate future RFCs.
Motivation and Context
Users often fail to find or install third party plugins to libOBS, resulting in additional support workload for both libOBS maintainers and support, as well as the plugin maintainer and support. This reduces that factor by adding an integrated and hopefully failsafe way to provide plugins.
Link to RFC
https://github.com/xaymar/obs-rfcs/blob/rfc1/text/0000-plugin-manager.md