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

Thank you very much.

Yours
David

2015-05-01 11:50 GMT+01:00 Dave Raggett <dsr@w3.org>:

>
> 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
>
> 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>
>
>
>
>