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.
