I was making what appears is an incorrect assumption that once we reported it works that changes were made to make the compatibility layer no longer necessary. Apparently that isn’t the case.
That compatibility was apparently provided through this compatibility layer, the removal of which is under discussion.
That was my assumption as well but now I wonder if there is more to it. If it’s just the imports, then those are changing again anyway so we either need to change the compatibility layer or we need change all the bindings.Right?
Indeed. Just look at the fundamental differences between the 1.x and 2.x versions of the Exec bindings. They are almost completely different in concept and usage. MQTT 1.x and 2.x it’s the same story.
The change that drove a lot of the original need for the compatibility layer were caused by:
- moving the core OH packages to the ESH package name space (i.e. the imports changed)
- in OH 2, bindings are not allowed to communicate directly with the Event Bus but in OH 1 bindings all communicated with the event bus.
The reason the OH 1.x Compatibility Layer is up for discussion is because we are now merging ESH back into OH and all those packages are changing again.
I for one, as a member of the AC, would vote against the change if that were to happen. We do not yet have enough OH 2.x replacements for heavily used OH 1.x bindings. It’s IMHO premature.
But, at the same time, from the users perspective the fact that there are not 2.x versions of all bindings is a problem. The fact that we can’t do anything through the REST API to create and configure Items bound to 1.x bindings means that as long as these 1.x bindings exist we will always have two configuration paths, two ways to do things, and this continued dual parallel paths for configuring and using OH.
As a user and someone who speaks for the users in discussions like these, if you take a 1.x binding and make it a 2.x binding with exactly the same capabilities and features, as a binding developer you may not think you are adding anything but from the user perspective you really are. It would be a huge improvement in usability and consistency from the user’s perspective. It is absolutely not a waste of effort and I encourage all maintainers of 1.x version bindings to please consider building a 2.x version of that binding.
David and Scott already have a plan to convert the Actions to 2.x and apparently it isn’t too hard. See OH1 Actions -> OH2 Actions - #3 by David_Graeff.
See my link above. I think that is well handled and I would hope this occurs regardless of what happens in this discussion.
This is the sticking point I think. In a year’s time what I’m hearing from the developers on this thread is they don’t want to be forced to rewrite their bindings for no clear improvement or new capability. I hope that my paragraph above will help some see that the mere fact that the same functionality is available in 2.x is an improvement all by itself. But that will not be enough.
If the Compatibility Layer is removed, we need to have a migration path. We need a developer who can migrate the remaining 1.x bindings to 2.x or we need something like David’s proposal to link a 1.9 and 2.x/3/x Event bus. Then those who are still stuck with 1.x version bindings because there is no alternative are not left behind. It’s not pretty and I’m not sure it is any better/simpler than maintaining the compatibility layer. But it could simplify the OH 2 core code while retaining support for legacy add-ons.
I think I agree. I don’t want to leave anyone out, even if one a few people use a given binding. However, a serious question that should be addresses is when do we consider a binding abandoned? What is the over all OH project’s responsibility for abandoned bindings?
I’m not at all saying that 1.x version bindings are abandoned, but I’m certain we have bindings (1.x and 2.x) that the maintainers have lost interest in and no one has stepped up to maintain. When a bug is discovered or a change necessary, what is the responsibility of the OH organization to keep up these abandoned add-ons? These are not rhetorical questions because that is really what we are talking about here. If we remove the Compatibility Layer we are declaring all 1.x bindings as abandoned and no longer supported. As I said above, I think that is premature at a minimum (even with the one year timeline). I’m on the fence as to whether it should ever be considered.
To a large extent yes I think it is. But if you have specific functionalities in mind I can confirm. However, the concepts between the two are very different, as you well know, so from a user’s perspective the two versions may work radically differently from a configuration and usage perspective.
I would hope I can convince some that it would not be pointless work. Hardly a week goes by where I don’t have to deal with new users who are confused by the two radically different setup and configuration models between 1.x and 2.x bindings, or those who don’t know whether it’s better to define their Items in .items files or in PaperUI, or those who install a 1.x binding and can’t figure out how to create Things, and so on. One or two such postings can be ignored. But one or two such postings almost every other day denotes a problem. It may feel like you are doing pointless work, but from the user’s perspective it is far from pointless.
It’s not so much changing the code base for the sake of it. There are not enough maintainers to the core of OH any more. This is an attempt to simplify the baseline to make better use of those few developers, and to avoid situations where there is only one expert on some subsystem (e.g. PaperUI) and that expert leaves the project leaving us with all this code we can’t maintain.
This too is an attempt to solve a real problem and not, IMHO, driven by philosophy or a desire to code for coding’s sake.
But what about a federated setup? I’m intrigued by the idea. It’s sub-optimal but feels like a workable compromise. OH 3 get’s it’s simplified code base, the legacy 1.x bindings are still usable now and into the future, and through the event bus federation we can have “one OH to rule them all.” It may slightly increase the maintenance workload if there are changes to the event bus contract, and as a user it will kind of suck to have to install and configure two OH instances. Everyone’s unhappy, sounds like a good compromise. 