Table of Contents Ⓜ️ Basic Concepts Devices Device Services Property Services Function Services Event Services Device Behavior Reactors Local Functions Ⓜ️ Meshes of Devices Security Cookies Ⓜ️ Workflows Static view of the Meadow world Dynamic view of the Meadow world Ⓜ️ Challenges Heterogeneity of Devices Processors Platforms Network Protocols Software Frameworks Ⓜ️ Requirements

• The Meadow world (or Meadow network) consists of devices.
  • A device is identified by its device name, which is unique in the entire Meadow world.
  • A device can be connected to the Meadow world by signing on to the Meadow network and get disconnected by signing off from the Meadow network or shutting down the device.
  • Q: Can we introduce the notion of hierarchy to the Meadow world? By using "hierarhical names", users can force some notion of hierarchy but, from practical implementation point of view, all device names must be maintained in a single name space, which may cause huge overhead.
• A device can interact with each other devices by providing and consuming services, where a service is one of the following three:
  • A device can have properties, whose values can be read or written either by itself or by other devices.
  • A device can have functions, which can be invoked either by itself or by other devices.
  • A device can generate events, which can be subscribed by other devices. When a device generates an instance of an event, it is sent to all its subscribers.
  • Each device service is identified by a name which is unique in the given device.
  • A device service is persistent in the sense that when a service is added to a device, the service exists acroos executions of MV runtime.
• A device can have have reactors, which define reactive behavior with respect to events.
  • Each reactor is identified by a name which is unqiue in the given device.
  • Also, in a device, the name space of services and reactors are not disjoint.
  • A particular service inside the entire Meadow world can be identified using the following scheme: <device-name>::<service-name>

• One can bind a reactor to an event so that whenever an intance of the event is generated, the reactor will be executed.

• Device can have a property, which has a unique property name within the device.
• A device property can store values, which allows devices to be stateful.
• A device property can be declared nonvolatile. Nonvolatile property can retain its value across executions of runtime.

• A device can provide functions to other devices.
• A function is a piece of code paramerized by arguments. It is CALLED (PULLED) by the caller (other device).

• A device can generate events.
• An event is a piece of code which represents that 'something has happened'. An interested device can subscribe to this event.
• An event is generated when the owner device of the event GENERATES (PUBLISHES) it.
• A special event, called timer is generated when specified interval expires.

• A device can have reactors.
• A reactor is a piece of code which is executed by the device when some event happens.
  • A reactor is not a service but rather a mechanism how a device behavior is defined.
  • Each device service can be "IMPLEMENTED" by reactors.

• A device can have local functions which is not callable from outside.
• This notion of local function is for traiditional sense of functions -- i.e. unit of code reuse.

• Devices will connect to each other and constitute a mesh of devices.
• Within a mesh of devices, they are considered as peers and there is no security check for message passing.
• Joining a mesh of devices requires security check.

• Like Erlang, security coookies are shared between peers.

A set of devices and services provided devices forms a static view of the world. This static view contains some static workflow (which may be implicitly represented as an event-reactor chain or defined as an explicit workflow).

An actual work is performed when there are some events which initiates work: e.g. human invokes a device service, timer expires, some Meadow event occurs and its instance is injected into the meadow world. Roughly, we say that any "initiating event" will enact a workflow -- or, a workflow is instantiated. An workflow instance consists of

• devices which are involved in a workflow
• device services which are involved in a workflow
  • event: event instances fired for this workflow instance; pending event instances (not ACK'd yet, etc.)
  • function: current stack contents; continuation point, etc.
  • reactor:

An workflow instance can be killed, suspended, and resumed as a unit.

• x86, ARM, Atmel, ...

• Operating Systems: Linux, Windows, Android, iOS, ...

• WiFi, Ethernet, ZigBee, Bluetooth, ...

• Google Nest, Apple HomeKit, AllJoyn, Electric Imp, ...