Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Binding MQTT to REST servers using Link: rel="mqtt"
Specifically for Ponte, which I just downloaded, if this resource


Returned the header:

Link: <tcp://localhost:1883>; rel="mqtt"; payload="PUT"; topic="hello"

Then clients that knew about rel="mqtt" would automatically know:
  • MQTT is available
  • it's at localhost:1883
  • the topic of updates is "hello"
  • the full updated resource is available  (payload="PUT")
What's beautiful about this is the It Just Works nature. Smart clients - assuming uptake of this idea - don't need to read the docs to figure out how to know if the resource they're querying is getting updates.

** Note ** : I'm going to change the spec I've written to assume the content-type is application/octet-stream.

Regards,
D.



On Mon, Jul 7, 2014 at 7:30 AM, David Janes <davidjanes@xxxxxxxxxxxxxx> wrote:
I've modified the docs to back off a little on REST and more clearly state "notifications about changes to a resource". 


I'm not sure if I follow that getting notifications to a REST resource is a dead end - or is it only a dead end because of the nature of MQTT? For example, if you consider a Facebook conversation a resource (this is reasonable), updates to the conversation are being usefully broadcast and received using MQTT. The only client that's disadvantaged by the scheme I'm proposing is one that would have been doing polling before but is depending on an unreliable broker.

Is this not a natural fit for Ponte? I.e. the HTTP API can inform it's clients that MQTT updates on the given Resource are being made available at a particular broker on a particular topic?

****

As an aside, I've actually been doing quite a bit of work on the "toggle the light" vs "turn the light on", specifically in the context of IOTDB.  I have quite the IoT workshop at home!. Note that IOTDB's primary goal is to _describe_ how things work, not a prescription of how things should work.

Even something as simple as turning a light on and off gets quite complicated:

* some devices only provide toggles, i.e. TV sets for turning on/off via IR
* if you're monitoring "is the light on/off" using the same variable as "send a commend to turn the light on/off" you're in for a lot of pain
* if you use the same variable for "send the command turn the light/on off" as "I have _sent_ the command to turn the light on/off" (and therefore I don't need to send it again) you can end up with situations where you can't control things anymore because it thinks it's already in the state you want to send.

D.



On Mon, Jul 7, 2014 at 2:35 AM, Matteo Collina <hello@xxxxxxxxxxxxxxxxx> wrote:
Hi David,

I think it's not really possible to have pseudo real-time notifications in REST. The protocol is built with a request/response semantic, plus it's key feature is caching. To my understanding, trying to follow pseudo real-time in REST is a dead end. However, my REST (HTTP/CoAP) <-> MQTT bridge (Ponte, http://eclipse.org/ponte) works very well in this scenario by acknowledging this very same fact.

MQTT has a key feature in retained messages. A very basic key-value store that allows you to store a value for each topic. If you just limit the REST API to the retained messages, you have the same basic semantic of a REST endpoint, and you can map them just fine. One caveat: you should not send commands 'toggle the light', but states 'the light is on'. Otherwise duplicated commands can lead to unexpected results. Let me know if you have more questions on this one. We might even join forces on this, Ponte is based on node.js so you might even reuse that for iotdb. Let me know :).

Anyway, good idea having a link header for MQTT topics, I think we should standardize that.

Cheers,

Matteo

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev


Back to the top