Configuration options with openHAB2

[ThomDietrich]

Sorry if I cited you wrong there. What I got from the mentioned thread is that while configuration files for things and items are there for now, they should become obsolete in favor of the database at some point.
I want to cite you directly:

@Kai

Our distro should be able to support both and also a middle path (which will probably be the majority of users when the discovery feature is used more and more by the first group).

I would be interested in your ideas how we could tackle the above problems. Do you always want to have full control through textual files? Or would you also trust a setup where all your settings are soaked into a binary database file? What would you expect the UI to do if you try to modify a file that you have defined yourself in the conf folder?

Here is my opinion on that: Talking only about items files for now, I was never a big fan of their structure. One line of item definition got quite long and you had a lot of repetition in them (due to the lack of “things”). To get some readability into the mess, most users build a table-like format into the file, the poor man’s database.

So, do I want my things and items in a configuration file? No, not ideally/necessarily.
Would I prefer a database? Yes, if it is still open for all needed modifications.

In your answer you are clearly distinguishing between people solely working with the configuration files and people working with the database through PaperUI. Furthermore you made clear, that PaperUI will never update the config files. There is a rift between the two user groups: people working with configuration files can not use the UI with all it’s nice supporting features (because it will not write back) and UI users can not do more special things, possible via config files (because there are no powerful interfaces). However I as a tech-savvy user do not want to exclude the PaperUI from my workflow and stay with a junky manually created file forever, I am looking for the mentioned “middle path”.

I want to vote towards the database approach in combination with what I and others mentioned before:

• Thing/item discovery and adoption through PaperUI
• Thing/item handling and modification though PaperUI
• Increase of UI functionality over time
• While there are not all functions available in PaperUI, mainly for the tech-savvy user:
• Direct database access through some existing frontend like phpmyadmin (not offered for mapdb? mapdb alternative an option?)
• More powerful options on the karaf console (random example: smarthome:items 5 rename 'Bathlight')
• RAW-view edit through PaperUI (compare InfluxDB data source | Grafana documentation → “RAW”)
• Export and import of all relevant data from the database to a human-readable file format like xml (as a last resort)

My proposal supports three things:

1. A clear transition from not-ideal items files to a more suited and system-managed database
2. Providing the right tools to aid the tech-savvy users to adopt to the new system while not being restricted to a UI
3. Motivate tech-savvy users to use AND contribute towards a powerful PaperUI