Suggestion: settings API to be used by core and plugins

[da-anda]

Please close this suggestion if it's not appropriate or if something like that already exists, but from what I have seen so far (still new to jellyfin) at least plugins currently have to provide their own settings HTML page and JS logic, which is IMO a really bad API design choice. Clients are unable to provide any of the settings unless it's the default web UI. And one change in the web UI can break plugin pages from what I gathered.

So my suggestion would be to abstract settings and their handling by using a declarative approach, like a XML, YAML or JSON schema that describes the settings options, their dependencies, visibility conditions (or handlers) etc, the core does read and manage those and the clients are only "dumb" renderers of these settings.
Ever since we switched to this in KODI, managing and extending settings as well as reacting to change events has never been so easy - even I as non C dev managed to add new settings.
The developer who implemented the base settings management handler wrote it in a way that is pretty much agnostic to KODI and can be used by any other project (from what he told back then), so if you wanted you could pick it up and write your own glue code (core interaction, event subscription, ...). If you are interested, this should be the core settings system he wrote back then https://github.com/xbmc/xbmc/tree/master/xbmc/settings/lib

I can provide more info or at least hook you up with people that could provide more info if you are interested. If not, please ignore my suggestion and simply close the ticket again.

Thanks.

[dkanada]

@MrTimscampi and I have been talking about this for a very long time, but we both really want to see it happen. There would need to be some kind of deprecation path in place, but the goal is to remove embedded HTML and JS from the server plugins. This would avoid a hard dependency on the web client for plugin configuration.