In my experience common sense isn’t that common. And if we just wait around for the users to get better we will ultimately fail. We have the power to change ourselves but not others.
This post and the little template are just two attempts we have made to try and help the users help us to help them. We are always open to further ideas. It’s not like we are ignoring the problem.
But we have our own constraints and will push back on ideas that exceed them.
I think the target is well defined. Perhaps it is not documented well enough. We would welcome any advice anyone has, and even better content, to address that. Then at least the group of uses who do read the docs will benefit.
If I’m talking to someone in the software industry I agree completely.
When talking to someone outside the industry, there is no difference between the two. Both activities are “programming” in their minds.
This is one of those places where I think it is better to go with the flow instead of introducing and describing new concepts that ultimately do not matter from a practical perspective.
I should amend my statement. My understanding is the goal to have one officially promoted and recommended way. I believe that many of the legacy ways will remain supported as long as feasible. But the documentation for the how to use them will become less prominate and will eventually become a subculture within OH, mind of like JSR223 is today.
OH too bad a concept for these three types of interfaces. It’s working furiously to improve the beginners interface (PaperUI) but it’s not there yet.
The Expert UI (text files) are the most mature but at some point something must be done to replace this. The current formats for the files are not aging well as new features are added and they use a proprietary format that doesn’t have the party libraries for reading and writing. At some point these files add they exist today will have to be dropped. Probably in an OH 3 time frame if I were to guess. I believe this is what David is referring to. It is frankly dumb to have two completely different file formats to define Things et. al. But maintaining legacy support sometimes forces us to do dumb things, at least for awhile.
OH has a very good REST API which is how all the web based UIs work.
You said it so much more concisely. 
All of what you say is true but it lacks context. In OH 1.x ALL we had were text configs. There were no UIs, no automatic discovery, etc. All we had were .items, .rules, .sitemaps, .persist, and one big openhab.cfg. We Only had yves’ expert UI.
OH 2 is an effort to build that beginner’s UI. And to achieve that it took completely rearchitecting the core and introducing concepts like Things.
The Most important thing to understand is that OH 2 is not done. We do not yet have parity between the old way and the new way yet and we need to get there. Most of the complaints you list all stem from the the fact that OH just isn’t done. For example, I know the Android app is undergoing changes to let it support HABPanel. I have great expectations for HABot as a UI. But once we do get to parity and everything that can or needs to be done can be done through one of the admin UIs, the old ways will have to change. They are not sustainable. I’m not saying that we need to get rid of text based configs. But the . text files as they currently exist will have to change. We cannot and should not maintain two completely separate configuration subsystems for OH.
Which can be done with JSONDB.
This process can continue unchanged with the only difference being which folders you check into and out of your source control. Instead of /etc/openhab2 you would control /var/lib/openhab2/jsondb.
I completely agree, that is why I do it with JSONDB. There is nothing special about it. It is just a series of JSON formatted text files. In fact, because the JSONDB format includes more information than you get in .things files (for example) the diffs and history is actually more useful than what you get from the .things files.
Pretty much all of this can continue, though there might be a problem because, at least for now, JSONDB cannot be edited while OH is running. So your button would need to shutdown OH, pull the changes, then restart OH.
@David_Graeff, this limitation is I think a long term problem that will need to be addressed. So far it is the only limitation I’ve been able to discern between the old text configs and JSONDB. Someone at some point will also need to write something to parse through the old .text files and convert them to JSONDB (perhaps through the REST API?) to ease the transition of users who are sitting on thousands of Items (for example).
To repeat what David said, JSONDB is a text file. You can do all of this with it.
Would David’s suggestion of having the ability to assign Things to a storage-context address this?
Everyone needs to realize a few things.
- We cannot continue to maintain the current format of the text config files. They are in a proprietary format and there are no libraries for readers or writers and they are based on a sub language whose future (IMHO) is in doubt.
- We cannot continue to maintain two COMPLETELY separate storage mechanisms for this sort of configuration. It is wasteful, will introduce errors, and introduces a whole lot of work that the project cannot sustain.
The text config files as they exist now will go away at some point.
So I’ll repeat David’s question slightly differently.
What would do you need the JSONDB to support in order to make it usable in your situation? So far I’ve seen two things which JSONDB doesn’t currently support:
- be able to edit it while OH is running
- be able to separate it into separate files instead of one big file for all Things (for example)
What else?
Speak up now because you have the attention of a developer who is actually willing to work on it. Don’t lose this chance!
I think everyone pretty much agrees. BUT the text configs as they exit right now are based on Xtend too. We can’t drop the one without dropping them all.