AI3 is the runtime user interface environment for Hexarc Programs. It is designed to run on a web browser.

Ideas and Concepts

  • We use a HUD-metaphor. A workspace contains a single central view surrounded by several auxiliary views. The central view always has the focus. Some auxiliary views can be switched to the central view; other auxiliary views are display only.
  • Workspaces are persistent (stored on the server).
  • We use WebGL (or at least support it), which means the programming model should support GPU-rendering semantics (e.g., shaders).
  • We support different programming abstractions to implement views. For example, a document oriented view is different from a canvas-type view. We might also have higher-level abstractions, such as a grid-UI.
  • A running program is a process. A process runs on the server and communicates with the view via messages.

The Archives

The Archives is the collection of all data accessible to programs via AI3, effectively all the data in the arcology.

Each archive is a top-level namespace defining the type of data, access method, and often storage location. All archives are hierarchical and have common access methods. Specific archive types might support additional access and manipulation methods.

Archives may overlap. That is, the archive containing all programs is actually a subset of the Aeon archive (which contains all tables).

Display Model

A workspace is an arrangement of one or more views, one of which is the central view, and the rest (if any) are auxiliary views. A view connects to one or more ports in a running program.

A workspace is associated with a single user (the user). A user may have one or more workspaces. Workspaces are persistent. The same workspace can be displayed on any number of devices. Changes made to the workspace on one device are reflected on all devices (though there may be a slight delay).

Workspaces only track the position and configuration of views. The underlying data for a view is managed by the specific running program. Workspace arrangements adapt to the device.

We connect running programs with views via ports. There are APIs for connecting, unconnecting, etc. Sometimes the connections are automatic (driven by the view or program) other times the user can make explicit connections.

Client to server communication is via message queue. When a workspace is open, the display calls an API on AI3 to get the set of messages for all views in the workspace. The display then distributes the messages to views as appropriate. Events on views are converted to messages and sent via API call to AI3, which then passes it on to the running programs (inside the Hexe engine). The Hexe engine manages the queues for input and output and there are APIs to access those queues.

Runtime Model

The Hexe engine runs programs. An arbitrary number of programs can run at the same time. Programs are single-threaded. A program consists of one or more functions. Only one function can run at a time. Some functions respond to specific event messages. Other functions run until they complete (spawning messages during their runtime and potentially listening for messages at appropriate points in their execution).

The same program image can run multiple program instances and the instances could communicate with each other via event messages. This might allow massively multiplayer games to scale.

Programs have APIs/functions to access persistent data. There are different kinds of persistent data:

  • Program data is stored in the process (as CDatum objects). Hexe is responsible for persisting these structures when the program terminates and loading them later.
  • User data is similar to global data, but associated with a user. Hexe will only load the data when the given user is asking for it.
  • Extended data is stored in AeonDB records. The program is responsible for manually loading and saving the data.

Abstraction Models

There are different kinds of program abstractions:

  • functional program: A functional program has no side-effects. It takes 0 or more inputs, computes (possibly for days), and outputs 1 or more outputs. It does not handle events, other than a well-defined set (run, terminate, etc.).
  • interactive program: An interactive program implements a user interface for manipulating some data model or API. Interactive programs can run forever handling events.
  • service program: A service program is a headless interactive program. It exposes an API but no user interface.

Examples

Command Shell

  • When a user opens AI3.hexarc.com, we call /api/connect and pass it the signed in user authtoken.
  • Inside /api/connect, we invoke the Hexe engine to create a session. The session has a message queue for communicating with the front-end.
  • We load a model of the workspace UI and store it as dynamic data in Hexe. Dynamic data has a sequence number so we can tell when it has changed.
  • /api/connect returns with a session ID.
  • We call /api/getDynamicData to get the data for our session.

Hello World Program

Editing a Program File

Development Plan

Phase I

Create a simple editor to create programs. This editor will ultimately get replaced by something implemented inside of AI3, but for now we use it to bootstrap.

  • URL is https://coder.hexarc.com.
  • We show the list of programs for this user, plus a button to create a new program.
  • When creating a new program, we call CodeSlinger to create a new program in Arc.programs. This will return the unique program ID. The user gives the program a name, which must be unique for the user.
  • The program itself is stored in Arc.source/{program ID}/{program name}.program
  • NOTE: For Phase I, all programs must have a single file. We cannot edit or create other files.
  • The entry in Arc.programs contains the program name (and thus implicitly a path to the main program file).
  • Arc.programs has a secondary index sorted by username and program name (program name unique for a user).

Phase II

  • Add AI2 commands to list programs for a user.
  • Add AI2 command to run a program (as a console program). We use an architecture similar to Arc.log. That is, Hexe keeps running process and saves output. AI2 polls to get the latest output.
  • Iterate on programming syntax/model.

Phase III

Status

  • 18 July 2020: Finished authorization code (sign in/sign out/register/change password). This includes JS code for talking with Hexarc. Started code to show a list of programs.
  • 12 July 2020: Started CodeSlinger archon, which creates Arc.programs, Arc.source, and Arc.code tables. Started Coder service, which will allow us to edit programs. Currently cloning Ministry code but without JQuery. Working on sign in dialog box. Need to implement code to talk to Hexarc via Ajax.