Re: web of things framework implementation challenges

:-)

this is essentially the same as our Sensible framework, which uses mDNS,
HTTP, JSON, etc --

http://sensible.mono.hm



On Mon, May 4, 2015 at 10:41 AM, Tran, Dzung D <dzung.d.tran@intel.com>
wrote:

> Dave,
>
>  I was wondering if you had a chance to take a look at iotkit-comm which
> is a NodeJS framework.
>
> >> Just an offer up for review is the APIs that was done for Intel(r)
> >>Edison.
> >> Here is the API spec:
> >>
> >> http://iotkit-comm-js.s3-website-us-west-2.amazonaws.com/api/index.ht
> >> ml
> >>
> >> Wiki:
> >>https://github.com/intel-iot-devkit/iotkit-comm-js/wiki/Iotkit-comm
> >>
> >> Code is on github here:
> >>https://github.com/intel-iot-devkit/iotkit-comm-js
>
> Thanks
> Dzung Tran
>
> From: "dsr@w3.org<mailto:dsr@w3.org>" <dsr@w3.org<mailto:dsr@w3.org>>
> Date: Monday, May 4, 2015 at 10:24 AM
> To: Public Web of Things IG <public-wot-ig@w3.org<mailto:
> public-wot-ig@w3.org>>
> Subject: web of things framework implementation challenges
> Resent-From: <public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>>
> Resent-Date: Monday, May 4, 2015 at 10:24 AM
>
> I have been happily hacking on a node.js implementation of the framework
> as presented in Munich
>
>     http://www.w3.org/2015/04/w3c-wot-framework-munich-2015.pdf
>
> This implementation relies on HTTP to retrieve thing descriptions in
> JSON-LD and WebSockets for communication between proxies and the things
> that they depend upon. Courtesy of node.js, the scripts are all in
> JavaScript.
>
> The starting point is when some server script wants to register a new
> thing for this server:
>
>       register_thing(uri, implementation)
>
> Note that uri must be a URI on this server that resolves to the thing’s
> description. The implementation is an object that must provide start and
> stop methods.  The above call retrieves the thing description and binds it
> to the implementation and calls the start method when all dependencies have
> been resolved.  As an example consider:
>
>      register_thing(‘/wot/agent.json, {…});
>
> where the agent, has the following description:
>
> // agent.json
>
> {
>   "@dependencies" : {
>     "door" : "/wot/door.json",
>     "light" : "/wot/light.json"
>   }
> }
>
> The framework then retrieves the descriptions for the dependent things,
> which are:
>
> // door.jon
>
> {
>     "@events" : {
>         "bell": null,
>         "key": {
>             "valid" : "boolean"
>         }
>     },
>     "@properties" : {
>         "is_open" : "boolean"
>     },
>     "@actions" : {
>         "unlock" : null
>    }
> }
>
> // light.son
>
> {
>     "@properties" : {
>         "on" : {
>            "type" : "boolean",
>            "writeable" : true
>         }
>     }
> }
>
> If the dependencies are hosted on the same server, we can bind the agent’s
> thing.door and thing.light to the corresponding objects.  Otherwise we need
> to create proxies for dependencies hosted on other servers.
>
> One challenge is where a thing is created before the things that it
> depends upon. We could be treat this as an error, or we could defer calling
> the new thing's start method until the dependencies have all been
> resolved.  This involves some book keeping on which things are pending on
> other things.
>
> Another challenge is the possibility of circular dependencies between
> things, and a deadlock where things are waiting on each other to be ready.
> In principle, this could be resolved by a flooding algorithm that traces
> the dependencies. This algorithm is otherwise known as a topological sort.
> A similar challenge is tidying up when things are stopped.
>
> My implementation is just an experiment, and a question for the security
> task force is whether servers need to execute each thing in its own
> sandbox.  That would complicate the implementation and I would be
> interested in chatting with people about potential solutions. JavaScript’s
> getters and setters provides a way to hide the security machinery that
> would be involved.
>
> Yet another challenge is how to expose the distinction between data and
> metadata for things. For now, I have made a simple convention of using
> underscore as a prefix for the names of metadata properties. This is
> strictly speaking a platform issue as it isn’t exposed externally by web of
> things servers.
>
> I’ve implemented bindings to WebSockets for the proxy to thing
> communication and it works nicely for events, property updates and action
> invocation. I have been able to demonstrate this for accessing things on
> the same server, and for accessing things from a web page script, although
> that requires the things to have the same origin and the web page (ignoring
> CORS for now).
>
> Here are a couple of examples of the experimental bindings to Web Sockets:
>
> If an event is fired on the thing, the thing server sends to all proxies:
>
> {
>   uri: thing's uri
>   event: event name
>   data: event data
> }
>
> If the proxy invokes an action on the thing it sends the following:
>
> {
>   uri: thing's uri
>   call: call id
>   action: action name
>   data: action data
> }
>
> The implementation provided for a new thing allows you to define an agent
> that controls other things. It also allows you to interface to sensors and
> actuators. Node.js provides a suite of modules for Bluetooth, ZigBee and so
> forth. I am therefore planning on demoing a thing that acts as a proxy for
> a Bluetooth Smart heart rate monitor.
>
> Although node.js is a great way to explore ideas for the web of things, it
> is not the only solution, and I expect that servers will vary considerably
> in their implementation, and the scripting languages that the support.
>
> A good test of this will be working on a server for a microcontroller e.g.
> the 8 bit ATMega328 processor as used in the Arduino Uno. This has a 16 MHz
> clock, 32 KB flash memory, 2KB SRAM and 1 KB EEPROM. There are several
> implementations of CoAP for the Uno, so a lot of the work has already been
> done.
>
> A related challenge is managing the communications metadata, given that
> IoT devices may spend most of their time in deep sleep to save power, and
> only wake up at scheduled intervals. A server with a proxy for a thing
> hosted on such a device will have to accommodate this schedule. Further
> study is needed to understand how this metadata is communicated. It sits at
> a lower level of abstraction than the metadata describing a thing’s events,
> properties and actions.
>
> One more challenge is provided by sensors where we need to log a time
> sequence of sensor values. These may be buffered and merged with data from
> other sensors for greater efficiency in the communications path. Does
> anyone have some good real world use cases for this?
>
> I plan to move my code to GitHub as soon as it stabilises, and make it
> available as an open source project.  Taking an experimental approach to
> the Web of Things, is a lot of fun, and helps to ground discussions in
> concrete examples.
>
> —
>    Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>
>
>
>
>
>