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

Well this is interesting and got me thinking

(1)

First, I'd like to make sure it's clear that I think we should not be
thinking "the state of a Thing is the Thing". Rather, the Thing is its
state(s), its model, and meta; which all function together but orthogonal

(2)

So (I am arguing)

   POST /light/1 { "on": true }
   PUT /light/1 { "on": true }

Are better expressed as

   POST /light/1/ostate { "on": true }
   PUT /light/1/ostate { "on": true }

Because you might want to also work with /light/1/model and /light/1/meta

Don't get caught up in me using "ostate" here - this will become clear why
below. Also if you believe POST should be on /light/1 I'm not overly caught
up about it

(3)

So let's examine the POST

   POST /light/1/ostate { "on": true }

which returns some new thing (in Michael's argument)

   /light/1/activity/X

The reason I've been arguing against this is because:

   - it doesn't model usually what happens in things, which is much simpler
   - everyone has to start looking for activities if they want to see if
   the light is in an interstitial state
   - the server has no idea when to dispose of the
   resource /light/1/activity/X
   - it's more complicated to implement

(4)

Here's my AHA moment. What is?

   /light/1/activity/123

*** it's _an_ ostate band ***, specific to the invoked POST.

(5)

So now this gives us an interesting unification

   POST /light/1/ostate { "on": true }

can redirect to the resource

   /light/1/ostate/123

or just (if the server doesn't want to be smart and just track all the
actions at once, which is IMO the usual case)

   /light/1/ostate

Note that I don't feel like you have to add a layer of hierarchy
(/activity/( - the band model lets you add as much as you want below the
thing itself.

(6)

Then this returns the "actual" state of the thing

   GET /light/1/istate

This returns the _unity of all actions_, to detect interstitial state

   GET /light/1/ostate

This returns the ostate of some particular action (if used)

   GET /light/1/ostate/123

(7)

The IOTDB model for ostate completion works here: everything transitions to
null in the ostate when the action is complete. I.e.

    GET /light1/ostate/123
    { "on": null }

Says we're done.

(8)

As a big bonus, you no longer need to differentiate between Properties and
Actions. They are invoked the same way and are "dealers choice" as far as
the server.

D.




On Thu, Jan 28, 2016 at 3:12 PM, Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> David Janes <davidjanes@davidjanes.com> wrote:
>     > 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.
>
>     > 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)
>
>     > 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.
>
> okay... so the RESTful analysis would tend to look at the problem
> differently.  (The example I recall was about rebooting a virtual machine)
>
> One would do:
>     POST /light/XXX      state: on
> one would receive a 201 Location: /light/XXX/activity/YYY
>
> A GET to /light/XXX/activity/YYY  would return the Interstitial State, with
> the current value retured, and possibly some other status, such as maybe,
> some kind of encoding: "power is on, but no current flowing, is bulb
> probably absent?"
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>