- From: David Janes <davidjanes@davidjanes.com>
- Date: Wed, 27 Jan 2016 09:03:29 -0500
- To: "t2trg@irtf.org" <t2TRG@irtf.org>, public-wot-ig@w3.org
- Message-ID: <CACp1KyPLZrY2-ax2pHcj+e1Zjr-9mFOxR2bJGAHmk9+hyRiakg@mail.gmail.com>
**** 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