MQTT Binding: Describing connection to the broker

[mkovatsc]

Issue #13 tries to use MQTT as example for a Binding for Event.

A problem is that MQTT is not stateless: a SUBSCRIBE needs a preceeding CONNECT. So there needs to be implicit knowledge, that the connection needs to be established before an Interaction can be performed. This can be seen similar to a TCP connection that needs to preceed an HTTP request. Yet what about the information that needs to go into the CONNECT message? Should it be specified, if yes where, or can it be left open (as MQTT has no clear rules for agreed values, e.g. for last will message)?

Any thoughts?

[mjkoster]

Yes, we will need some kind of "host" management for reusing connections. There needs to be a list of connections and credentials in the server and some default behavior.

[mkovatsc]

We could leave the "host management" to the client (not sure why you say list in the server, as no server in MQTT and the broker does not open connections).

The critical part is to figure out if the CONNECT need special information or can be built implicitly from a topic URI and the security metadata. Maybe we need more general communication metadata, i.e., someone needs to analyze the concrete requirements (e.g., last will message format) and come up with a proposal (i.e., TD extension).

I can give some pointers from implementing security metadata support in node-wot.

[mjkoster]

Yes, I do mean in the client, there needs to be connection information for each broker such as credentials, keep-alive, and the instructions for closing the connection.

Where we are today assuming one base URI and one set of security metadata, there could be many in the case of pub/sub brokers, hence the idea of a list.

[egekorkan]

I am guessing that this could be done in the forms on the Thing level where with an MQTT vocabulary one can describe the broker URI, client id required, security mechanism etc.