Re: [TF-AP] Follow-up to today's call

> On 30 Apr 2015, at 21:10, Jason Proctor <jason@mono.hm> wrote:
> 
> let's see if my understanding gels with yours and the panel's :-)
> 
> a WoT server is an entity which is discoverable somehow and acts as a proxy for a WoT device, which of course may share the same physical and/or logical space with the server itself. a WoT client can be anything which supports discovery and (minimally) HTTP.

Essentially, yes, but a clean architecture is about keeping different levels of abstraction distinct.  As far as the Web of Things is concerned you just have things as virtual objects that are hosted on servers with the ability for one thing to be a proxy for another, perhaps on a different server. At this level of the architecturel, we don’t mention protocols or devices since that is at a lower layer.

> once the server is discovered, the client communicates with it using standard Web technologies. the server may serve up some HTML with effectively serves as a user interface for the device, or it may serve up JSON for config and property lists, etc, and it may also support a WebSockets type interaction for more real-time or notification based use cases. additionally it may support a REST type interface for modifying config and property values on the device.
> 
> sound reasonable?

Yes pretty much, apart from the need to decouple service logic from the communication layer.

If you have a script that wants to access a thing, the starting point is the URI for the thing's description. Your script calls an asynchronous platform API to retrieve the description and set up a virtual object in the script’s addressing space as a proxy for the thing. The platform, your script is executing on, also handles the communication layer, so that your script is decoupled from the underlying protocols. Your script can thus access properties of the thing via accessing properties on the virtual object acting as the thing’s proxy. JavaScript (as an example of a scripting language) provides support for custom property getters and setters, that make it easy to hind the bindings to the communication layer.

A given server may expose multiple protocols, e.g. my experimental server exposes HTTP and Web Sockets. This gives developers the freedom to support an HTML based  browser interface for services, but only if that is appropriate.

Discovery is about finding URIs for things, e.g. through asking servers what things they host, through traversing the links in the descriptions of things for their dependencies on other things, and through local discovery protocols, including listening to beacons (Google's Physical Web). When you have a script that registers a new thing, its description will include the dependencies of this thing on other things. This allows the platform to automatically set up proxies for those things and expose them as named objects in this thing’s execution address space.  The platform also provides the house keeping needed to free up proxy resources when they are no longer needed.

> this proposed tech stack could live on an Arduino (and indeed only the unreliability of the CC3000 chip is holding us up at the moment), so if you could somehow put both a Wifi shield and a servo shield on an Ard, then the proxying Raspberry wouldn't be necessary. (not that node + Pi isn't a killer WoT server platform.)

Right.  A microcontroller with an embedded CoAP server and a 6LoWPAN wireless interface would be an example. This would typically involve another server, e.g. a home hub, or even a smart phone. For a very long battery life, the device with the microcontroller would spend most of its time asleep. It could periodically advertise itself for discovery purposes (when instructed to do so), and its metadata could provide information about the time slots when it will be awake and listening for communications.

I am looking for what hardware would be best for demonstrating the Web of Things.  So far I’ve looked at heart rate monitors, servo and stepping motor control, lights switches, and basic sensors (temperature, gas, etc.). Arduino looks  the easiest path. Note that I already have a Raspberry Pi which could be pressed into service as a home hub.

What platforms do you think will be killer WoT server platforms?

A further idea for demos involves robot control with simulated robots, e.g. SimSpark or Webots. This would be useful for demonstrating control with smooth interpolation between data points.

> personally i think Bluetooth has too many limitations to serve as a primary WoT protocol, and likely Bt devices would be proxied onto a WoT network by IP or an equivalent. but that might just be my ignorance showing.

I tend to agree, but am still coming up to speed on the Bluetooth technical specs.  An example is for heart rate sensors:

    https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=239865 <https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=239865>

This defines the role of a “Collector” that collects data from the sensor over the Bluetooth 4.0 GATT protocol. This collector could be implemented as part of a WoT server.   I don’t envisage using Bluetooth to transfer WoT descriptions. The Bluetooth specifications already cover local discovery and device identification. A WoT server acting as a “collector” would be able to map this into a WoT description.

Is this any clearer?

I am hoping to make my experimental server and browser library available soon, as a concrete example of the architecture.

Best regards,
—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>