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

2. WoT Thing needs to have istate/ostate Bands

From: David Janes <davidjanes@davidjanes.com>
Date: Wed, 27 Jan 2016 04:33:01 -0500
Message-ID: <CACp1KyNGYAwx2dg2-m9ga+oF231iDE4YjB5+v_F1Mg9dLgre_g@mail.gmail.com>
To: "t2trg@irtf.org" <t2TRG@irtf.org>, public-wot-ig@w3.org
****
Formatted Version:
https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/2.%20WoT%20Thing%20needs%20to%20have%20istate:ostate%20Bands.md
****

2. WoT Thing needs to have istate/ostate Bands

Points:

   - WeMo Model
   - Interstitial State
   - What do the properties return?

<https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/2.%20WoT%20Thing%20needs%20to%20have%20istate:ostate%20Bands.md#wemo>
WeMo

Consider the WeMo Switch, a popular "stater" IoT device. Turning a light
off to on looks like this.

Stages:

   1. the switch is *off*
   2. the user sends *turn on* command / the WeMo receives it
   3. about 300ms (guestimate) passes
   4. the switch is *on*

It's step (3) we're considering.
<https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/2.%20WoT%20Thing%20needs%20to%20have%20istate:ostate%20Bands.md#wot-thing>WoT
Thing

So let's look at this as a WoT property manipulation. Note that I'm just
pseudocoding this, I don't know if there's a property called exactly "on"
but I'm sure there's something like it.

thing.getProperty("on")         ## (stage 1) a promise that yields false
thing.setProperty("on", true)   ## (stage 2)
thing.getProperty("on")     ## (stage 3) WHAAA?
thing.getProperty("on")     ## (stage 4)

<https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/2.%20WoT%20Thing%20needs%20to%20have%20istate:ostate%20Bands.md#the-contradiction>The
contradiction

It's Stage 3 that's the concern. We don't have a clean way of knowing that
we're turning on the light, but the light is currently off.

This is called the "Interstitial State" and it's important that this is
indicated in the UI.

Now, the immediate objection might be "Well, thing.setProperty('on', true)"
returns a Promise that will tell when the the light turns on. But *this is
not sufficient* because *thing.getProperty("on")* might be called *somewhere
else in the code* or *by someone else entirely in a different process*
<https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/2.%20WoT%20Thing%20needs%20to%20have%20istate:ostate%20Bands.md#the-solution>The
solution

Break up the properties into two states:

   - the *istate*, the "input state", the actual state of the thing
   - the *ostate*, the "output state", the state we're trying to transition
   to.

These are independent

Now our code looks like this

thing.istate.getProperty("on")      ## (stage 1) a promise that yields false
thing.istate.setProperty("on", true)    ## (stage 2)
thing.istate.getProperty("on")      ## (stage 3) FALSE
thing.ostate.getProperty("on")      ## (stage 3) TRUE
thing.istate.getProperty("on")      ## (stage 4)

Or even more simply if we make the assumption that the istate and ostate
are basically views of the properties

thing.istate.get("on")      ## (stage 1) a promise that yields false
thing.istate.set("on", true)    ## (stage 2)
thing.istate.get("on")      ## (stage 3) FALSE
thing.ostate.get("on")      ## (stage 3) TRUE
thing.istate.get("on")      ## (stage 4)
thing.ostate.get("on")      ## (stage 4) NULL - "nothing happening"
Received on Wednesday, 27 January 2016 09:33:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 27 January 2016 09:33:54 UTC