I think shorty707’s comment gets close to what I think could be a viable solution to making text files and other confuration mechanisms coexistst, as Kai Kreuzer puts it.
A key issue in this discussion so far has been the fact that config files are read-only (and I think they should be), which makes overriding anything they specify difficult to do, if you don’t want to either confuse your users and at the same time make the system accessible.
Hence, the two (read-only config files + dynamic configurations) must be unified with some finesse.
I’d like to see a tiered system, where OH2’s 1st place to look for config files is the conf/
directory.
The 2nd place to look, would be any form of dynamic configuration that was done through the (web) UI/karaf shell. This 2nd tier could also be a way for OH2 to override whatever is defined in conf/
.
In order to not confuse power users, there should be a facility to prevent such overrides. E.g. by adding a final: true
flag to a configuration file’s section, users can stop OH2 from ever creating any other representation of this section.
At the same time, the (web) UI should contain a section that clearly lists all configuration bits and pieces - regardless of whether the plugins involved support this kind of introspection - and for each of those display where it was loaded from, and whether it was marked final
. On top of that, a button should also be added to each, that erases any overriding definition and reverts the respective config back to what is defined in the text file.
Lastly, a reliable & universal config export facility can help power users and beginners alike to understand in what ways changing the settings in the (web) UI would affect their textual configs. This feature could look like a button next to each config item in the aforementioned list, which opens an exported view of said config item, including all overriding properties that were created from the (web) UI.
I would like to extend this logic not just to the configuration of plugins, things and sitemaps, but also to the plugins themselves, meaning the binaries that power each plugin.
As you can tell form my comment, I think most of the issues brought forward in this discussion can be managed by providing visibility into what OH2 is doing, as well as means to explicitly & interactively control that.