MQTT version 5.0 support #308
The MQTT version 5.0 specification is nearing completion, with the availability of working draft 15 (https://www.oasis-open.org/committees/documents.php?wg_abbrev=mqtt&show_descriptions=yes), which is going to be, with very minor changes, the first Committee Specification Draft (CSD). This means that we are nearing the end of the process of creating the MQTT 5.0 specification. There is a 30 day review period for the CSD once it's officially published, then if changes are needed as a result of feedback, there will be a second CSD with a further review period, and so on. We anticipate that two CSDs will be sufficient.
To facilitate MQTT v 5.0 adoption and awareness in the community, and give feedback to the OASIS TC within the CSD review period, James Sutton and I are proposing to start work on implementations in Eclipse Paho. The rough plan is:
The text was updated successfully, but these errors were encountered:
MQTTClient (synchronous) API design:
Functions to manipulate properties:
MQTTProperties_add(MQTTProperties* props, MQTTProperty* prop)
MQTTV5Response* MQTTV5Client_connect(MQTTClient handle, MQTTClient_connectOptions* options, MQTTProperties* connectProps, MQTTProperties* willProps);
MQTTV5Response* MQTTV5Client_disconnect(MQTTClient handle, int timeout, MQTTReasonCode, MQTTProperties*);
MQTTV5Response* MQTTClient_subscribe(MQTTClient handle, const char* topic, int qos,
int MQTTV5Client_publishMessage(MQTTClient handle, const char* topicName, MQTTClient_message* msg, MQTTClient_deliveryToken* dt, MQTTProperties* props);
MQTTV5Response* MQTTV5Client_publish(MQTTClient handle, const char* topicName, int payloadlen, void* payload, int qos, int retained, MQTTClient_deliveryToken* dt, MQTTProperties* props);
For the async client, we already have option structures on each call which can be extended to include properties. For connect and disconnect:
int MQTTAsync_connect(MQTTAsync handle, const MQTTAsync_connectOptions* options);
We don't need to change the return code because the MQTT V5 Reason Code and properties will be returned in the success/failure callbacks.
For the other calls, the MQTTAsync_responseOptions structure can be extended to include properties which are input options, so the only real fly in this ointment is the name of the structure. We could create a synonym for that type so (MQTTAsync_callOptions or something) so that it didn't just imply it was for responses.
int MQTTAsync_subscribe(MQTTAsync handle, const char* topic, int qos, MQTTAsync_responseOptions* response);
The upshot is that I think we could end up only changing the structures rather than the API calls themselves. We'll need the operations on properties like the synchronous client as well of course.
The Paho C++ and Rust libraries just wrap the Async API, so I'm mostly looking at this last comment. This seems like a reasonable way to proceed, with minimal disruption to the existing API and apps.
I wonder if, in C++, there might be a new class, call_options, that derives from the existing response_options, to signal intent. But I'm just thinking out loud.
BTW, nice use of const. :-)