The system as a whole is called ARGON; but given all the other modules that comprise an ARGON node's kernel, all that's left to be "ARGON" itself is the code shared by components that doesn't fit into any one component, yet doesn't deserve a component in its own right.

The ARGON module comprises:

* HYDROGEN code for the first stage of the kernel startup sequence. This initialises IRON, and CHROME, then compiles and runs HELIUM, LITHIUM, NITROGEN, WOLFRAM, and all the other kernel components.

...and doubtless many other little utilities that are needed in time will accumulate.

Here's a diagram showing roughly how the components fit together on a running node.

Variations in Node Configuration

I've written the above boot process for running a "full" ARGON node that handles both TUNGSTEN storage and runs LITHIUM handlers.

However, a node might be configured without any TUNGSTEN mass storage devices, and have to access everything remotely via WOLFRAM.

Likewise, the three main sources of LITHIUM handler requests - MERCURY/CARBON networking and CAESIUM scheduled events - should be individually configurable on a node. Whether a node is published in the volume ID for external requests or not is configurable, and allows nodes to be set up that only handle intra-cluster requests. Turning all of these off would make a node that exists purely for TUNGSTEN storage.

Embedded Systems

ARGON can also drive embedded systems, too.

At the most basic level, HYDROGEN, optionally with HELIUM and/or IRON and CHROME as well, is a fine low-level platform for embedded development. Such systems aren't full ARGON nodes as they don't run WOLFRAM.

But it should also be possible to build an ARGON node without TUNGSTEN, without WOLFRAM distributed processing or CAESIUM, and only accepting MERCURY requests to its NITROGEN node entity - which then provides functionality to access the embedded system's custom software. Such a node could join a cluster, purely to provide a single volume/node entity representing itself.

Also, not all nodes need to be part of a cluster. WOLFRAM will happily support a cluster with only one node in it, which can be grown later, but it is possible to set up a node with local TUNGSTEN storage and entities and everything, but without WOLFRAM. It would have a node entity which is also a volume entity, but no need for cluster entities.

Thin Clients, Fat Clients and Mobile Devices

A thin client in the ARGON world is a node that just provides a NEON interface, letting a user log into a user agent by downloading a user interface to run locally. It might be part of a cluster for ease of administration as a whole, and it might have TUNGSTEN storage for local caching, but it wouldn't mirror any volumes.

A public thin client might provide its own user interface without a user agent; its CARBON browsing and NEON user-interfacing would just be anonymous, or identified as from the actual node entity of the thin client device itself.

However, a more powerful device could join a cluster as a roving node and mirror the user agent entity itself. Public access to the user agent would be through the mirrors of it on non-roving nodes in the cluster, but the local copy allows for operation when the node is isolated from the cluster, and resynchronisation upon reconnection. That could earn the term "fat client".

Mobile devices such as tablet computers and smartphones can provide full general NEON user interface capabilities like either of the above, or go for a more specialist interface, optionally connecting to a user agent entity through a MERCURY endpoint that lets them access private state such as address books and messages, much like modern smartphones connect to sync and messaging services.