mv basics - modrpc/info GitHub Wiki
- 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:
- x86, ARM, Atmel, ...
- Operating Systems: Linux, Windows, Android, iOS, ...
- WiFi, Ethernet, ZigBee, Bluetooth, ...
- Google Nest, Apple HomeKit, AllJoyn, Electric Imp, ...
- A Meadow namespace should provide a namespace (i.e. name-? table) of devices and services.
- The naming of devices should be independent of the transport address which can change over time.
- A namespace coincides with the security-enforced domain.
- A namespace is maintained by a special device called NAMESERVER. Any device which runs name service is a NAMESERVER. Every device must have at least one NAMESERVER.
- Namespace can be linked to form a larger namespace.
- After two namespaces, say A and B, are linked, a device in one namespace can access a device in another namespace.
- Devices in namespace A can access any device in namespace B by using a prefix "B:".
- ANALOGY: UNIX hierarchical file system
- Two linked namespace can be unliked whenever it's not necessary to be linked.
- A device should be able to export three services to the outside services.
- property service
- event generation
- RPC
- A device should provide a way to modify its own behavior.
- Internally, this is a reactor but users don't need to know reactors.
- To users, it's just adding callback to an event.
- add_callback(event, (*fun)());
- Service must be deployable statically or dynamically.
-
Name service
- Any device that provides name service is a NAMESERVER.
- Name service is just a set of RPC functions used to maintain namespace.
- NAMESERVER maintains (device, addr) and (linked-namespace-nameserver, addr)
- A process is defined as an execution of event-reaction sequence.
- The lifetime of a process begins with a firing of a root event and ends until all the reactors fired by the event instance finishes their execution.
- Should a process be a singleton (like Verilog process) or a forked thread?
- A process call chain is defined as the sequence of function calls and/or event-reactions, starting with an event instance which wakes up a process. The first event must be either a timer event or an external event injected from outside (e.g. user's touchscreen input).
- A method for killing all related processes in a process call chain must be provided.