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

(1)

My contention is that a real physical Thing will have multiple states which
are very closely modelled by "istate" / "ostate". Furthermore, these
provide a simple, elegant and understandable representation of what's going
on in the Thing.

(2)

A Thing doesn't correspond correspond to a single document / "resource".
There's a bunch of things that are basically orthogonal to each other (e.g.
istate / ostate / meta / model) and can be cleanly thought of as having
their own URLs, as being separate resources.

(3)

Yes, you can assume that there's only a single state (corresponding to the
ostate) with a Thing and everything else involves applying Actions to a
Thing. At the cost of complexity on the server, loss of reliability (when
do you get rid of Action state?), and additional work for consumers of the
state (I now have to start observing _other people's actions_).

If you look at e.g. the Hue, or the WeMo, or TCP Lighting, or a Denon AVR,
or KNX, or the Sonos, or the Chromecast, or any other thing I've actually
picked up and work with: they all do stuff by (sometimes in odd ways I
admit) PUT some value to some place, not "create an Action, and track it
through to completion".

SmartThing's device (code) API works by "find the device, call a function
(e.g. PUT), time passes, a event is triggered, and you read (GET) the new
state". Right here:
https://github.com/dpjanes/iotdb-smartthings/blob/master/smartthings.groovy

(5)

There is a lot of danger in creating a  _prescriptive_ IoT standard, e.g.
"here's what you have to do", not least of all that there's so many of them
right now.

I'm a strong proponent of "let's describe what Things actually do" and try
to create interoperability and compatibility from there, e.g. _descriptive_
standard.

Regards,
D.

On Wed, Jan 27, 2016 at 2:35 PM, Michael Koster <
michael.koster@smartthings.com> wrote:

> " 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 has it right, but let me elaborate some. Assuming REST properties
> as defined by Fielding in The Document for the purpose of this discussion.
>
> http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
>
> It seems like we're trying to add a notion of temporality to a state
> machine, or
> more likely confusing the delays between state transitions with
> meta-states in
> the server.
>
> The state machine is the REST interaction between client and server.
>
> The client applies a method to the server, the server changes state, the
> client
> receives a resolution of the Promise indicating the new state.
>
> Between these actions, there are many delays, like network transmission
> and buffering, the server processing time, time waiting for resources in
> the
> client or server, then there could be network switches, satellite links...
> It's the internet.
>
> These delays aren't part of the state machine, and they are occurring in
> the signals between the state transition. The server doesn't know when
> the client initiated the request with the deferred operation. Only the
> client has a meta-state while it is waiting for the Promise to resolve.
>
> The rest of the system is not in a meta-state. The resource has no
> meta-state.
> Resource state will either be observed in the "before" state or the
> "after" state,
> or some other state from a request from some other client. A resource in
> REST has exactly one state.
>
> Does a client observing the state of a resource need to know that some
> other
> client's request may have reached the sever first? No, that is not the
> nature of
> REST. REST has no global consistency model.
>
> If operations from >1 client need to be serialized in some global
> consistency
> model, another serialization control needs to be added to the system. This
> will most assuredly break the scalability property of REST.
>
> Observing some intended state that may or may not ever be observed in
> the resource state doesn't seem to add anything to REST.
>
> Long running actions are different. Long running actions are cases where
> the
> resource state may change multiple times during the processing of the
> request. You may be tempted to call this a meta-state but since the state
> observed by each client is a separate self-contained representation and
> we don't try to introduce a global consisteny model again, it still seems
> to satisfy the REST constraints as defined by Fielding.
>
> The design of WoT.Action is to allow the server to make multiple state
> changes
> to a request and transmit those as needed in representations as needed.
> Another
> client may observe these state transitions and may be allowed to add
> another
> action if those are still in progress. A client state machine may also be
> advanced
> by intermediate states in the server as it executes the action. If we want
> to use
> Deferred/Promise pattern for this we need to add something between request
> and resolution of the promise. An update or multiple fulfillments or
> something.
>
> Note that from the client's point of view, a long running Action is still
> a state
> machine. No temporality is assumed. It's no different from e.g. CoAP
> Observe.
>
> So I would conclude that IoT using REST does not benefit by adding an
> istate/osate
> construct.
>
> Best regards,
>
> Michael
>
>
>
>
>
>
> On Jan 27, 2016, at 11:56 PM, Kerry Lynn <kerlyn@ieee.org> wrote:
>
> 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
>
> _______________________________________________
> T2TRG mailing list
> T2TRG@irtf.org
> https://www.irtf.org/mailman/listinfo/t2trg
>
>
>