AP breakouts Montreal F2F 2016
Topics
Resource Patterns:
- Property
- e.g. Measured Temperature, Color state
- - suggestion: GET / PUT a resource
- Collection
- e.g. a group of properties, config values, GPIO pins, etc.
- - suggestion: resource pattern like e.g. core interfaces collections
- Action
- e.g. dimming of a light, brewing coffee, runing a dishwasher program
- POST to an action resource
- - suggestion: for long running actions: sub-resource for execution tracking (GET/PUT/DELETE)
- Event
- e.g. doorbell, current power cosumption, it starts to rain
- - suggestion: resource that updates the state and keeps at least the last knwon state
- Subscription
- e.g. subscribe to an event, the update of a value or the execution of an action
- - suggestion: resources to manage subscriptions, e.g. like [RestHooks](http://resthooks.org/docs/)
- Binding
- e.g. on/off property of lightswitch and lightbulb, temperature of sensor and input of HVAC
- - suggestion: "bind" or "connect" to interactions together on the thing level, protocol binding specifies how to synchronize the state
Abstract Messages / Schema of the thing-models:
- Actions: calling, state
- Lifetime: registering
- Event Notifications
- Subscribing
- Binding a resource to another resource
- Metadata as opposed to payload data model
Scripting APIs:
- Consuming Things
- Factories:
- Discovery
- Thing description
- Proxying another thing
- Local
- Interaction
- subscribing
- calling actions
- read/write properties
- Factories:
- Exposing things
- Factories:
- Thing description
- Programmatically creating a thing
- Proxying another thing
- Interaction
- event handling
- spontaneous
- Factories:
Error conditions:
- abstract list of error conditions
- can be mapped to protocols
- can be used by APIs
- integrity constraints
- what expectations can we put on the interactions/messages
Architecture Model:
- Dataflow of Plugfest demos as a base for the required messages (e.g. event description level)
- Deployment views
Minutes
AP & DI:
Deployment scenarios:
- A) Single-Thing WoT Server on device directly controlled by WoT client in local network
- B) in addition to (A), also discovery and control from remote (through internet)
- C) Home hub is a servient that is a local proxy of electronic devices, and is accessed like A/B. Discovery between hub and devices is local.
- D1) Shadow is a servient acting as a remote proxy (e.g. on the cloud), discovery of shadow is remote
- D2) Both shadow and hub to enable local discovery for the hub and remote access and discovery via the shadow
- D3) industry case: local servients abstract industrial protocols, accessed or proxied by local clients.
- D4) Car gateway providing WoT server inteface to car-specific interfaces, accessed remotely
- E) Servient-to-Servient interaction, client/server roles for interaction determined by appliation. Variation of scenarios A-D.
Findings/Questions:
- need a building block: how to create and sync virtual instances / shadows of a thing?
- need to investigate how these servients find each other
Interactions for discovery:
- local
- be discoverable
- discover
- remote
- be discoverable
- discover
API primitives:
discovering is covered by current practises Registering/Advertising need to be specified
Factory functions for thing object:
AIs
- Structure for scenarios out of the Contributions of Fujitsu and DI
- API primitives for the "Registering/Advertising" part of the discovery
- Define Lifecycle for Proxies / virtual shadows
- Possible Plugfest proposal: have an example script using client/physical API, check interoperability