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

On Thu, Apr 30, 2015 at 11:41 AM, Dave Raggett <dsr@w3.org> wrote:

>
> On 30 Apr 2015, at 13:55, Hund, Johannes <johannes.hund@siemens.com>
> wrote:
>
> Dear Task force,
>
> following up on today's call I want to circulate the contributed sketches
> of the Architecture as well as the Protocol & API-sketch.
>
>
> My regrets for today’s call, I have been travelling on work and unable to
> call in.
>
> For my part, I really have a very simple architecture in mind.  This is
> holding up well with the implementation work I am doing in odd moments of
> free time. The essence is the relationship between a thing and another
> thing that acts as its proxy.  Things are normally hosted by servers, but
> may be hosted by web pages.  To connect the web page to the server, I am
> using HTTP to download the thing description from the server, and a shared
> WebSocket connection for the messages between the proxy and the proxied
> things. Web page scripts are restricted by the same origin security policy.
> This means that the web page can only proxy or depend upon things on a
> server with the same “origin” as the HTTP server the web page was loaded
> from.  This restriction doesn’t apply to servers which are free to
> communicate with whichever other servers they choose to.
>
> When it comes to interfacing to sensors, I have been looking at Bluetooth
> medical sensors where there is a logical domain data model coupled with a
> communication model.  For actuators, I have been looking at servos as used
> in robot arms and robot vehicles.  The servos are driven from
> microcontrollers like the Arduino which in turn are controlled by a more
> powerful device like a Raspberry Pi. For easy of prototyping, node.js is
> particularly good due to the wide range of open source modules available.
> This allows for the development of different kinds of things as appropriate
> to the different kinds of sensors and actuators.
>
> —
>    Dave Raggett <dsr@w3.org>
>
>
>
>
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.

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?

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

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.