Micro service architecture for bindings

[mgeramb]

Provide an REST API or MQTT API for bindings

Advantages:

• Bad implementations of bindings could not crash the whole openHAB
• Bindings can be written in any language, e.g. node.js could be much more easier for REST based bindings
• Bindings could be started on other computers

Disadvantages:

• More hardware resources needed for the overhead

What do you think about this?

[rkoshak]

It seems like an MQTT API kind of already exists in the MQTT 2.x Homie standard. Would this not be sufficient? It has automatic discovery and everything.

Similarly, what is lacking in the current REST API? Ultimately a binding issues updates or commands to Items (ignoring Thing Channel events for a moment). The current REST API fully supports both operations, and I believe there is a web socket or the like to subscribe to events on Items. There might be something that might need to be done with the Channel triggers perhaps. I don't know the Things end points that well.

Ultimately I don't think this is an AC issue at this time. It is only a request for additions to what is currently there so there should be no impact to the rest of OH. My recommendation is to open an issue and discuss with the core maintainers and/or start work on a PR.

[mgeramb]

It seems like an MQTT API kind of already exists in the MQTT 2.x Homie standard. Would this not be sufficient? It has automatic discovery and everything.

There seems to be a misunderstanding. This AC have nothing to do with the current possibilities. I'am speaking about an architecture change under the hood which is not visible to users. It is definitely too early for a PR on this. Maybe I was too technical here. Please read the AC as:
Each Binding should have it's own process
In this way it is more open for any suggestions how it can be done. Let us first talk about the architecture direction and as follow up discussion how it can be done.

[rkoshak]

It may be too early for a PR, but it still isn't yet a discussion for the AC. Open an issue and discuss this with the core maintainers. Only if they cannot come to a consensus would the AC be brought in to break the impasse.

But, based on my current understanding of the directions the maintainers are going, they are looking to refine the 2.5 architecture and purge some of the old stuff carried over from OH 1.x, not radically redesign the architecture which a proposal like this would require. But I'm not one of those maintainers. You don't need to convince me. You need to convince them. So you should start by opening an issue and seeing where the discussion goes.