...is a JavaScript platform (ala node.js, narwhal, the browser, etc) that targets multiuser, rich media applications. It is released under the "Simplified", 2-clause BSD License.

• A hybrid native/JavaScript platform, comprised of one-or-more Workers
• Workers are shared-nothing, isolated JavaScript VMs
• SpiderMonkey (that other JavaScript engine) is the library used for JS execution
• Each Worker runs in its own OS thread, like:
  • One Worker blocking the main thread and managing the overall process lifecycle
  • Zero-or-more additional Workers running on separate threads, as needed
• Communication between Workers via a JSON-based, asynchronous message passing scheme
• All messages originate from a Worker to another known Worker, like:
  1. Worker-A subscribes to a message via a string URI, providing a callback to handle messages for that URI
  2. Worker-B (who may actually be Worker-A) publishes a JSON message for Worker-A (by it's unique identifier) and the same URI
  3. Worker-A gets the message and processes it (using the supplied callback), eventually, in addition to any other work it may be doing
• Consequently, spawning order is important and natural parent/child hierarchies will form
• Each Worker is completely synchronous (and single-threaded) within the context of its own lifetime

• CoffeeScript as a first class language (and vanilla ECMAScript 5.1, as well)
• Bindings for 2D graphics and keyboard/mouse input using the SFML v2 library (sugs-richclient)
• 2D, rigid body physics via the Chipmunk Game Dynamics engine (currently in sugs-core as the ChipmunkPhysicsComponent, soon to broken into its own lib)

• The Worker abstraction encapsulates:
  • OS threading
  • An isolated SpiderMonkey JSRuntime* and all the trimmings
  • An in-process, asynchronuos messaging mechanism (innovatively named the MessageExchange)
• Everything else is implemented via Components
• Components allow a Worker to take on additional capabilities
• This includes things like:
  • Running a user script (ScriptRunnerComponent)
  • Bindings for various 3rd part libraries (ChipmunkPhysicsComponent, RichClientComponent)
  • General-purpose filesystem access (FilesystemComponent)
• As hinted at by the examples above, Components serve to both:
  • Embed new capabilities within a Worker besides the defaults (thread asynchronicity, JavaScript-execution and inter-Worker messaging)
  • Provide a way to deliberately compartmentalize/manage those capabilities
• A Worker's Components are specified at spawn-time

Native libs

• SpiderMonkey
• boost
• SFML
• Chipmunk

JavaScript Libs

• CoffeeScript 1.1.1
• Underscore.js 1.1.7
• Sugar.js 0.9.4

Hells yeah, we do. It's called sugs-spec and follows the rather blah but useful Context/Specification format.

• Transparent, inter-process/network messaging
  • the existing abstraction ought to scale out with the addition of an onConnect type handler so that the 'receiver' of a new connection can be notified of remote Worker(s) trying to make contact with it
• A WebGL abstraction, hewing close to existing browser APIs
• Persistance support (google's leveldb and/or sqlite)
• Windows and OSX support
  • currently all development is happening in a 64bit Ubuntu VM, but the above-named platforms are intended targets
• libuv-based event loops for all Workers (we truly are converging on node.js, heh)

Too bad.