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

" 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 <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