|
Version0 /
1bAccessorsSpecificationAccessor specifications are organized according to three levels described in the Accessors white paper (Interface, Component, and Composition). This specification describes the current Michigan prototype described in the Michigan accessors concept paper. This page is a working document, describing version 0.1b of a design for accessors. ResourcesInterfaceAn accessor interface specifies what it requires of an accessor host, what its inputs and outputs are, and various pieces of metadata such as author, version, etc. An accessor interface may extend another interface, in which case it inherits the inputs and outputs of the interface that it extends. An accessor has an interface and an implementation. The interface may extend one or more other accessor interfaces. A key property of the interface of an accessor is that a host can tell whether it can instantiate an accessor by examining its interface. For ease of construction, we provide an interface specification in JSON and XML (they are isomorphic). The specification is available here https://github.com/lab11/accessors/blob/master/server/ACCESSOR_IR.md . ComponentA component accessor has an interface and a script. The script defines one or more functions that are invoked by the swarmlet host, and can also define local state variables used by the accessor. In version 0.1b accessors, an accessor may define some number of action functions. The accessor context is the execution environment from the accessor perspective, it is a defined set of interfaces (functions) that is available for accessors to use. The accessor runtime is the execution environment in which an accessor runs. An accessor runtime must adhere to the context specification, described here. The runtime is responsible for providing implementations of all of the functions made available to accessors in an accessor execution context. This specification defines a common environment that ensures that accessors will operate correctly whether run in a node.js host, a Ptolemy II host, a Python host, etc.
The accessor runtime also exposes and extensive runtime library. This is a collection of functions that abstract away host-implementation-specific details such as how to open sockets or issue http requests. All library functions are placed into a
The requires tag in the interface specification for an accessor declares all modules required by the accessor. The built-in versus optional distinction is for accessor authors. Thought from Pat: It would be interesting to explore accessors that "gracefully degrade", e.g. support partial functionality if bluetooth isn't available. That really complicates the port contract, where some ports suddenly "wouldn't work". Perhaps we could do something creative such as transparently creating permutations of accessors with and without ports. This would let accessor authors write code with optional ports (intuitive for authors) but let the framework preserve the stronger port model. We expect in the future that base classes other than JSAccessor will be developed. The goal would be for other runtimes to use the same top-level API for interacting with the accessors ecosystem. The set of built-in versus optional modules may shift, however the interfaces should be able to remain identical. CompositionFIXME |