The principal goal of Hexarc is to enable rapid, scalable, and maintainable development of web apps. It is designed to be the "web service stack architected for the web age". That said, getting from here to there is going to take lots of work and precise execution. This article describes the desired solution and plots a path to achieve it.

Key Scenarios

We would like to handle the following scenarios:

Rapid Prototyping: I come up with a cool idea for a program and want to implement it quickly. Once implemented, I'd like to show it off (let people run it) and/or share it (let people develop their own versions).
Automation: I want to periodically download data, store it somewhere, and then run analysis over it. Or perhaps I want to monitor the performance of my server and have it alert me if there is trouble.
Procedural Graphics: I want to write a program that generates images (like Luminous or Processing). This can automatically take advantage of distributed rendering. Plus programs can be shared easily.
Simulations: I want to write a gravity simulation and take advantage of distributed computes.
Games, Part I: I want to create a backend for a game.
Games, Part II: I want to create a browser game.
Web App: I want to create a web app (such as Ministry) that can scale to the whole world.
Tracker App: I want to create a custom, record-based app for a line-of-business: a tracker, a scheduler, a coordinator. Sometime slightly more structured than a shared spreadsheet, but just as easy to create.

Core Concepts

No single development environment can satisfy all of the above scenarios. Instead we propose development multiple environments, each optimized for a specific scenario, and sharing concepts and services.

Abstraction Level

We define the abstraction level of a development environment as follows:

LEVEL OUTPUT           NOTES
-------------------------------------------------------------------------------
 0    Hexarc Module    E.g., Microsoft Visual Studio.
 1    Hexarc Service   We expect <100 services per arcology.
 2    Hexarc Program   Env implemented as a Hexarc Service.
 3    Custom           Focused abstraction

Level 0: An environment that generates native code for a module, e.g., Microsoft Visual Studio. We don't need to worry about this level, other than by providing documentation, sample code, etc.
Level 1: An environment that creates Hexarc services such as Ministry. Currently this is done via offline text editor and AI1 upload. This level is mostly designed for people who will run their own arcology. It is unlikely (I think) that we will allow arbitrary people to create Hexarc services on Hexarc.com. We only need one level 1 environment and it should ship with Hexarc. The codename for this environment is Monolith.
Level 2: An environment implemented as a Hexarc service that creates and runs programs for all users. This is a Visual Basic (or Turbo Pascal) spiritual successor. Since this is a general purpose environment, we only need one. The codename for this environment is Alchemy.
Level 3: An environment with a well-defined and constrained abstraction. For example, a programmable list-based system (a Lotus Notes spiritual successor). Ministry could be extended with more programming capabilities to become a Level 3 environment. These environment have a constrained abstraction, so we would expect there to be many level 3 environments.

Hexarc Module

A Hexarc module is a native program running as one or more processes on one or more machines. Modules are fully trusted in the arcology; only arcology administrators are able to add modules.

A Hexarc module communicates via Hexarc messages.

A Hexarc module generally does not communicate with the user directly. Instead, a Hexarc service usually exposes a user interface and invokes module messages as appropriate.

Modules are registered with Hexarc.com. An arcology (including Hexarc.com) may install modules from the master list. We store several module versions on Hexarc.com to deal with upgrades. An arcology administrator may choose when to upgrade a given module (although some modules may have version requirements on other modules).

Some modules, such as AeonDb are built in, meaning that they are guaranteed to exist on all arcologies. Built-in modules should always be backwards compatible.

Hexarc Service

A Hexarc service is an application running on top of the Hexarc arcology. It is implemented in some Hexarc languages, (currently HexeLisp).

The most common kind of Hexarc service serves HTTP requests. The service is assigned a range of the URL namespace, usually by hostname. That is, a hostname is handled by a single service (though a service might handle multiple hostnames).

A Hexarc service can be fully trusted (an admin service) or sandboxed. Sandboxed services cannot read or modify anything outside their sandbox. Modules enforce this by checking the resource prefix. For example, the Ministry service can only access tables with the prefix "Ministry."

A Hexarc service may rely on one of more modules. The service may refer to one or more modules (and their minimum version). If those modules are not present, the service will not run.

A Hexarc service may expose one or more service commands. Depending on permission, a service command may be called by another service, or by a user from the AI2 console.

We also use service commands for unit tests. With appropriate attributes, we can define a command as a unit test.

Hexarc Program

A Hexarc program is a user-created bundle of code. Unlike Hexarc services, which can only be loaded by administrators, any user can create a program (though they might have limited permissions). Whereas we expect < 100 services in an arcology, there is no limit to the number of installed programs, and the number of running programs is limited only by arcology resources.

A Hexarc program can be as simple as an AI2 console command (in fact, we should re-implement all console commands as programs). Or it can implement an entire web service (using multiple endpoints and embedded resources).