The Jarvis Specification

This serves as a complete specification of the structure, organization, and functionality of Jarvis:

Overall Architecture

The application is separated into the Core and Modules.

-------------------------------------
| Core Application                  |
|                                   |
|  --------------    -------------  |
|  | Module #1  |    | Module #2 |  |
|  --------------    -------------  |
|                                   |
-------------------------------------`

While the Core has direct access to hardware, it is up to the untrusted 3rd-party modules to create useful data for the user. The Core is able to manage the permissions of each of these modules. Modules are able to chain together.

--------------
| Module #1  |
--------------
      |
      | (typed)
      |
      v
--------------
| Module #2  |
--------------

Module Structure

|- Module Directory
|--- Manifest File (package.json)
|--- Main File (index.html)
|--- Supporting JS/CSS Files

package.json example:

{
  "title": "GPS Module",
  "permissions": {
    "sensor": ["gps"],
    "output_type": {
      "name": "GPS Data",
      "fields": {
        "latitude": "float",
        "longitude": "float"
      }
    }
  },
  "description": "Produces GPS Data for other modules to consume.",
}

Events

Data Communications

All data in Jarvis is considered to be structured and typed. Since we are using JSON as the intermediary language between the Modules and the Core, typing becomes a matter of defining (key, value type) tuples that a module is interested in.

For example, in this snippet of data, a tuple of ("times_eaten", int) would match:

{ "times_eaten": 5 }

Our data type system allows for for data to conform to rules that only match a subset of its features. For example, the following data would match the rules ("latitude", float) ("longitude", float) despite the fact that it contains an extra field (altitude).

{
  "latitude":   64.3,
  "longitude": -37.5,
  "altitude":   -100,
}

If a module requested data matching the rules above, the fields not explicitly requested (altitude) would be stripped out.

Outside of the type system, all module-to-core and inter-module communications is handled by a Javascript API that allows information to flow into (and out of) the sandboxed iFrames that modules live in.

The following is a cursory list of expected API functions:

• getData
• publishData

Data Permissions

• sensor - Access to a specific hardware sensor (possible values: gps, gyro, accelerometer).
• network - Access to a specific network resources (e.g. https://*.google.com).
• input_type - Access to a specific type of data as input.
• output_type - Ability to export a type of data to other modules.

Where input and output type is in the form of a data type. Data types in JSON are specified as:

{
  "name": "GPS Data", // The human readable name shown to users when they want to assign a module to this data type.
  "fields": { // An object of fields where the key is the field name and the value is the type of data stored in the field.
    "latitude": "float",
    "longitude": "float",
  }
}

A field is analogous to the idea of "tuple matching-rules" in the above sections.

Permissions may include other metadata in order to determine the quality of the data accessed.

For example, gps resolution:low frequency:4h can be used to show that the module only needs low resolution GPS data at a frequency of once every 4 hours.

Presentations