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

6. WoT Thing should move to a Band Architecture (Conclusion)

From: David Janes <davidjanes@davidjanes.com>
Date: Wed, 27 Jan 2016 09:03:29 -0500
Message-ID: <CACp1KyPLZrY2-ax2pHcj+e1Zjr-9mFOxR2bJGAHmk9+hyRiakg@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/6.%20WoT%20Thing%20should%20move%20to%20a%20Band%20Architecture%20(Conclusion).md
****

The Band architecture

The WoT Thing should move to a Band architecture, specifically:

   - istate - to model the "input state", the actual state of a Thing
   - ostate - to model the "output state", for sending commands /
   transitioning the State
   - meta - to store all the metadata
   - model - to store the Model, which defines what the values in "istate"
   and "ostate" mean

It's possible that there are more bands that could be added, for example
"reachability" (though I would lightly argue this belongs in the metadata).
<https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/6.%20WoT%20Thing%20should%20move%20to%20a%20Band%20Architecture%20(Conclusion).md#what-it-removes--adds--changes>What
it removes / adds / changes

What we've proposed massively cleans up the Thing definition.

For reference again

interface Thing: EventTarget {
    readonly attribute DOMString id;
    readonly attribute DOMString type;
    readonly attribute DOMString name;
    readonly attribute boolean reachable;
    attribute EventHandler onreachabilitychange;
    Promise<any> callAction(DOMString actionName, any parameter);
    Promise<any> setProperty(DOMString propertyName, any newValue)a;
    Promise<any> getProperty(DOMString propertyName);
    void addListener(DOMString eventName, ThingEventListener listener);
    void removeListener(DOMString eventName, ThingEventListener listener);
    void removeAllListeners(DOMString eventName);
}

Basically we end up really needing is:

* id: the immutable ID
* band() (to retrieve a particular band)
* on() - or addListener if you prefer
* removeListener()
* removeAllListeners()

And a Band interface that looks like this

* set()
* get()

And possibly also:

* first()
* list()
* on()

There would be also something to invoke an Action, which as argued earlier,
I believe should return a new Thing.
<https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/6.%20WoT%20Thing%20should%20move%20to%20a%20Band%20Architecture%20(Conclusion).md#what-it-looks-like>What
it looks like

Note there's other ways this could be coded, but they're basically all
isomorphic to this:

## change the name
thing
    .band("meta")
    .set("schema:name", "David's WeMo");

## get the name
thing
    .band("meta")
    .get("schema:name")     ## could be a string, list or null
thing
    .band("meta")
    .first("schema:name")   ## guarantees one thing
thing
    .band("meta")
    .list("schema:name")    ## guarantees a list

## wait for metadata changes
thing
    .on("meta", function(...))

## wait for something specifically to change in metadata
thing
    .band("meta")
    .on("schema:name", function(...))

## reachability change (assuming we make reachability its
## own band - IOTDB includes it as metadata
thing
    .on("reachability", function(...))

## directly manipulate a term: not that great, because we don't
## necessarily assume "on" or "powered" or "o" or whatever
## means that the thing is on
thing
    .band("ostate")
    .set("powered", true)

## __semantically___ manipulate a term: way better!
## note that "iot-purpose:on" needs to be looked up in the meta band
thing
    .band("ostate")
    .set("iot-purpose:on", true)

## get a current value __semantically__
thing
    .band("istate")
    .get("iot-purpose:on")

<https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/6.%20WoT%20Thing%20should%20move%20to%20a%20Band%20Architecture%20(Conclusion).md#what-it-adds>What
it adds

This also makes creating APIs trivial, it simplifies the code base, it
makes it easier for data to be moved around.

Here's an example of Transports built around this infrastructure. All the
data needed to work with the Things is in here, and the code to do so is
almost trivial.

   -
   http://homestar.io:20000/api/things/urn:iotdb:thing:REST:6acd18449fe571d3a1d12ef66aa443dd:rest-dimmer-light
   - coap://
   184.107.137.234:22001/ts/urn:iotdb:thing:REST:6acd18449fe571d3a1d12ef66aa443dd:rest-dimmer-light
   - mqtt://
   184.107.137.235:20001/runners/0a6ad141-e2f2-407e-a4a3-e0403821b6e9/api/things/urn:iotdb:thing:REST:6acd18449fe571d3a1d12ef66aa443dd:rest-dimmer-light
Received on Wednesday, 27 January 2016 14:04:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 27 January 2016 14:04:20 UTC