Open mjacoby opened 8 years ago
Yes. It has been discussed in the SWG meetings. Different ways have been proposed, discussed, and analyzed. At the end, the current way is adopted. There are always pros and cons. The good thing about current way is that the pattern of HTTP POST and MQTT is the same. No confusion there. There should be more design rationales for this decision. Anyone can help out Michael?
Regarding the question of no responses from server after MQTT create, MQTT is a light-weight protocol. It is not like HTTP. It doesn't have a response mechanism.
Thanks for the clarification. Having URLs/topics with the same name between HTTP and MQTT is of course nice but I think in this case the drawbacks outweigh this as MQTT clients will receive messages they neither want to receive nor expect to receive and they must filter these message out. Furthermore, it is not explicitly stated in the standard that this is a known issue and should be taken care of when subscribing to observations via MQTT.
I personally could image another MQTT topic structure something like this
Subscribe to entity sets
v1.0/Things/update
for changes/updates on Thingsv1.0/Things/create
for notification about insertion of new Thingsv1.0/Things/delete
for notification about deletion of Thingsv1.0/Things
for all types of notifications (create, update, delete) encapsulated in an JSON object containing the type (create, update, delete) of eventSubscribe to entity
v1.0/Things(1)/update
for changes/updates of Thingv1.0/Things(1)/delete
for notification about deletion of Thingv1.0/Things(1)
for combined information about update/deletion of ThingSubscribe to property
v1.0/Things(1)/name/update
for changes/updates on property name of a Thingv1.0/Things(1)/name
could be alternative URL for this as only updates make sense for propertiesSubscribe to entity set with select
Just like subscription to entity set but with additional ?$select=property1,...,propertyN
after the entity set name
v1.0/Things?$select=id,name/create
v1.0/Things?$select=id,name/update
v1.0/Things?$select=id,name/delete
v1.0/Things?select=id,name
Creating observations
v1.0/Things/create/request
for publishing create requests to the serverv1.0/Things/create/response
for receiving feedback if an insertion was successfulThis also addresses the issue of providing feedback on the success/failure of an observation create request via MQTT by introducing an extra topic only for feedback.
As the standard is now officially published in version 1.0 this can be seen as input for discussion on future versions.
Finally had a quick look at the MQTT v5.0 overview, and one new thing that would be perfect for this issue is:
User properties: Add User Properties to most packets. User properties on PUBLISH are included with the message and are defined by the Client applications. The user properties on PUBLISH and Will Properties are forwarded by the Server to the receiver of the message. User properties on the CONNECT, SUBSCRIBE, and UNSUBSCRIBE packets are defined by the Server implementation. The user properties on CONNACK PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK and AUTH packets are defined by the sender, and are unique to the sender implementation. The meaning of user properties is not defined by MQTT.
If we add support for MQTT v5, we could put the type of change (create, update, delete) in such a user property. That means we don't need separate topics for create/update/delete, unless we specifically want to be able to only receive create messages. Right now I can't think of a use-case where one would want create, but not update/delete messages.
Request / Response: Formalize the request/response pattern within MQTT and provide the Response Topic and Correlation Data properties to allow response messages to be routed back to the publisher of a request. Also, add the ability for the Client to get configuration information from the Server about how to construct the response topics.
This means we can respond to create messages, with either an error or success code. We could even completely mimic the HTTP interface, by setting the HTTP Method as a user property, and answering with a response.
The issue of double-messages does not seem to be solved by MQTT v5. So we might still want to keep the "/request" topic postfix for sending messages to the server.
Quick overview of 3.1.1 vs 5.0: https://github.com/mqtt/mqtt.github.io/wiki/Differences-between-3.1.1-and-5.0
As for creating an observation via MQTT and subscribing to new/changed observations the same MQTT topic can be used (v1.0/Observations) all requests to create a observation from one client to the server are received by all other clients watching the observations entity set. Personally, I find this quite ugly as now each client subscribing to changes will also receive requests from other clients to the serve to create observations on the same topic and has to do some content checking (e.g. check if the payload does not contain an @iot.id than it is a observation create request) to distinguish what is really a change and what is a request from another client to the server which I'm not interested in.
Are you aware of this issue and is this design on purpose? Have you though about any nicer way to handle this while writing the standard?
Furthermore, there is no feedback from the server to a client requesting the creation of an observation via MQTT. Is this also on purpose?