Mqtt implementation needs improvements

[relu91]

I've recently worked on #456 and I had the opportunity to have a look into the current implementation of the MQTT binding. I think it can be improved in multiple points, some of which may impact also the binding specification.

• [x] Missing the ability to self-host the broker. I think that the server implementation should be able to self host the broker not only connect to an external remote node.
• [x] Missing a correct definition of the configuration parameters. For reference please have a look into the current HTTP implementation where the client has a properly defined interface in the http.ts for the config object.
• [x] Client implementation lacks the ability to connect using user and password
• [ ] Proper definition of form parameters. Now QoS and retain are not really used in the code. We need to implement a proper model in the binding document.
• [x] Unit tests are not self-contained but depend upon core libraries. I think we should just test the protocol APIs rather than the full stack in a binding package. Or if we want to test the full stack we should provide smaller tests that just focus on binding APIs.
• [x] Refactor the expose function in smaller units (but this is a problem of almost every binding).
• [x] Refactor client implementation to have the same code style of other clients (e.g., it uses method = () => {} instead of public method(){})

[egekorkan]

Some comments:

• Self-hosting: For the Thing simulator we have, we are using an node based broker called aedes. See: https://github.com/tum-esi/shadow-thing/blob/dc5bcbabcb75e1fe8281e3a5bfeafb548c056720/src/cli.ts#L287
• For username/password, you mean Consumer cannot connect right? Also, it does not happen through the servient config like it should

[relu91]

For username/password, you mean Consumer cannot connect right? Also, it does not happen through the servient config like it should

yeah, it doesn't even implement setSecurity method.

[relu91]

After reviewing #562 I added another point to the list above:

• Refactor client implementation to have the same code style of other clients (e.g., it uses method = () => {} instead of public method(){})

Basically the client uses another style to define class methods: https://github.com/eclipse/thingweb.node-wot/blob/82b97b186d3de0d04836f7dc3378b0b7c22580d3/packages/binding-mqtt/src/mqtt-client.ts#L95-L100

[danielpeintner]

relates to https://github.com/eclipse/thingweb.node-wot/issues/569

[egekorkan]

Regarding the remaining item about qos and retain:

• We should make sure that the Consumer follows the forms requirements. If the form has a specific qos or retain value, they should be copied to the publish request. At this example: https://w3c.github.io/wot-binding-templates/bindings/protocols/mqtt/index.html#example-qos, it is indicating the Consumer to use those parameters.