- From: Kerry Lynn <kerlyn@ieee.org>
- Date: Wed, 27 Jan 2016 11:56:24 -0500
- To: David Janes <davidjanes@davidjanes.com>
- Cc: "t2trg@irtf.org" <t2TRG@irtf.org>, public-wot-ig@w3.org
Received on Thursday, 28 January 2016 08:48:14 UTC
David, I think you're hitting on something important with the notion of "interstitial state", but I wonder if it's a special case of a more general concept - the freshness (or fidelity?) of istate? I've seen systems that assign timestamps to istate and ostate. If a command is issued through the API then ostate timestamp is modified. Reading istate through the API returns ostate and istate timestamps. If the relation istate_ts < ostate_ts is true then the returned istate is unreliable. There is also the problem of devices that can be manually as well as program- matically controlled. To detect an out-of-band state change, the device either needs to push the new state to the authoritative data store, be observed by the data store, or be polled by the data store. Observation exists in some transports but not others and push requires additional configuration, therefore polling seems like the lowest common denominator. Polling raises the question "how frequently should I poll?" These questions seem to touch on the philosophy of state transfer in REST. The "real" state resides in the device and any representation of that state that resides elsewhere would seem to be stale within some epsilon. Kerry
Received on Thursday, 28 January 2016 08:48:14 UTC