W3C home > Mailing lists > Public > public-wot-ig@w3.org > January 2016

Re: [T2TRG] 2. WoT Thing needs to have istate/ostate Bands

From: Kerry Lynn <kerlyn@ieee.org>
Date: Wed, 27 Jan 2016 11:56:24 -0500
Message-ID: <CABOxzu3u2M4WJuQO4r34B5iVrV_fhMUv5nizCmAwVHoGJSuooQ@mail.gmail.com>
To: David Janes <davidjanes@davidjanes.com>
Cc: "t2trg@irtf.org" <t2TRG@irtf.org>, public-wot-ig@w3.org
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

This archive was generated by hypermail 2.3.1 : Thursday, 28 January 2016 08:48:16 UTC