Not logged in

XENON is not a part of the ARGON abstract specification - it's not even a component of an implementation of ARGON. Instead, it is a suite of libaries written in other programming languages, either implementing useful ARGON concepts that can exist in isolation, or to interoperate with actual ARGON nodes.

Most of them will be in Chicken Scheme as that's my programming language of choice, but implementations in other languages will be useful, too - particularly for IRON and MERCURY.

The components I propose are:

The system console abstraction from HYDROGEN

Long-running daemon software such as network services tend to require logging, monitoring, and management of some kind, and most end up implementing their own as an after-thought. The HYDROGEN console interface is designed to provide a high-level interface to this, and could be implemented as a library providing the abstract interface, passing output on to a list of handlers. Prompts for input will be broadcast to the handlers, and the first handler to "claim" the request will cause it to be cancelled on all the others; and asynchronous command inputs from any of them will be merged together to feed to the application.

The default handlers are a console-based one (using ANSI escapes) and a Web interface, as well as an sexpr-over-tcp-socket protocol that can be used to run handlers in a separate process. Finally, a handler that logs output to files configurably, and can run arbitrary shell commands (also configured in the same file) upon system status transitions, completes the set.


An implementation of IRON for Scheme would be most useful. The representation used in-memory should use existing Scheme types such as vectors and lists where possible. IRON symbols are a little trickier; Scheme symbols should probably be mapped to the default namespace, and namespaced IRON symbols mapped to Scheme record types, as should IRON records. The implementation will consist of tools to manage the in-memory representation of such IRON types with no direct Scheme equivalent, and writer/reader implementations for the textual and binary encodings of IRON. Implementations of IRON in C will be somewhat trickier, due to the requirement for an implementation of the full type system, ideally including garbage collection.


An implementation of the IRIDIUM protocol (using the IRON binary reader/writer) will provide a useful toolkit for network protocol construction, especially when used as the basis for a full MERCURY implementation. Of course, what counts as a cluster and what counts as an entity will be up to the applications that use it; users of the library will need to provide cluster cryptographic keys and a versioned list of nodes, and will be able to use arbitrary values of their own choosing as entity IDs.


Given an IRON implementation, a basic CHROME interpreter can be written. Indeed, a CHROME to HYDROGEN compiler written in CHROME could be run on the interpreter in order to bootstrap CHROME onto HYDROGEN. But the interpreter could be used to experiment with the practicalities of the CHROME language, and rapidly iterate the design; a hand-coded interpreter written in HYDROGEN will probably be harder to tinker with.

The task scheduling from HELIUM and LITHIUM

Parts of these two can be used to build a thread/job pooling mechanism in the spirit of Apple's Grand Central Dispatch; a managed for queues of tasks (implemented as Scheme closures), with metadata, and a set of threads to run them.


Using an IRON implementation, CARBON knowledge bases (both in memory and accessed via MERCURY) and inference could be implemented in Scheme. Again, this might be useful in its own right (especially coupled with a TUNGSTEN-esque persistent store, perhaps built on SQLite), as well as providing a prototyping environment for CARBON itself.