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.
- Implementations of IRON for various languages would be most useful, competing with JSON, s-expressions and XML. The representation used in-memory should use existing base-language types such as vectors and lists where possible. The implementation will consist of tools to manage the in-memory representation of IRON types with no direct base-language equivalent, and writer/reader implementations for the textual and binary encodings of IRON. Implementations of IRON in languages like 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.
- 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.
ARGON Client Libraries
- If ARGON starts to become popular for Internet application development with FLUORINE, then there might be scope for implementations of a basic "ARGON Client" in various languages. Such a beast would contain an IRON implementation, an IRIDIUM implementation, a basic MERCURY client (probably limited to anonymous and pseudonymous authentication), and a CARBON implementation including CARBON-over-MERCURY, thereby enabling non-ARGON code to fully access the resources of ARGON entities.