- From: <john.nj.davies@bt.com>
- Date: Thu, 28 Jan 2016 22:33:34 +0000
- To: <davidjanes@davidjanes.com>, <t2TRG@irtf.org>, <public-wot-ig@w3.org>
- Message-ID: <65de07d1170143699e600026a932515f@rew09926dag10c.domain1.systemhost.net>
David, This is new to me and I have just checked out your Slideshare overview presentation – looks interesting. Are you aware of the Hypercat specification: a lightweight, JSON-based spec for describing IoT resources (actually could be used in principle to describe anything you care to ascribe a URI to). As you advocate, it is based on JSON and RESTful tech for low barrier to participation. Hypercat has a small mandatory core of metadata elements and can be arbitrarily extended as required with additional elements. If interested, take a look at: http://www.hypercat.io/standard.html There is also a serialisation of Hypercat in RDF. Regards, John Davies. From: davidjanes@gmail.com [mailto:davidjanes@gmail.com] On Behalf Of David Janes Sent: 27 January 2016 09:33 To: t2trg@irtf.org; public-wot-ig@w3.org Subject: 2. WoT Thing needs to have istate/ostate Bands **** 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? 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. 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. 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 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 Thursday, 28 January 2016 22:34:08 UTC