A human's view of an ARGON system is as a bunch of entities.

Each physical server or workstation is known as a node in my terminology; a group of nodes under common administrative control is connected as a cluster, enabling a certain level of trust between the computers comprising the cluster to reduce communications overheads, cooperate on common goals, and to ease administration. Generally, the cluster will usually be administered as a whole, rather than individual nodes; unless initial installations or hardware upgrades are involved, operations like upgrading software will be performed on the whole cluster as one.

The cluster cooperates, using TUNGSTEN and WOLFRAM, to create the illusion of having one giant shared disk for storage of entities. It's like a distributed file system.

Entities are the applications, services, and files in the ARGON worldview. They are things you can see as icons represented in folder entities and double click on to open up. They are composed of data - their state - which is replicated across the cluster, and code in CHROME or another language to provide an interface to that state via MERCURY. The code is either stored (in source form) within the entity itself, or referenced in CARBON.

Within each entity, TUNGSTEN maintains a knowledge base, sort of like a PROLOG system's state, but divided into sections which may carry differing levels of trust.

CHROME modules of source code are contained within the entity as top level objects; the modules can then import resources from each other by naming the top level object containing the module, and the name of the exported symbol. Resources may be imported from shared modules stored in CARBON by creating a top-level object containing, instead of a CHROME module, a reference to the CARBON name of a module.

Every cluster is addressed by a cluster ID, as described on the MERCURY pages; this ID contains information required by clients to contact the nodes in the cluster that are configured to accept external MERCURY requests, and to authenticate the cluster.

Each entity has an ID, which consists of the cluster's ID, plus an entity number (of perhaps 32 bits), plus an optional persona field. This is to allow the entity to provide any number of public faces; the classic example of this is an entity providing a gateway to, for example, SMTP email. When accessed without any persona field, it provides a user interface allowing you to enter an SMTP email address, and returning an entity ID - which is the ID of that same entity, with the email address stored as a string in the persona field. When accessed with a persona field containing an email address, however, the entity instead provides the IODINE mailbox delivery interface, with an implementation that actually converts the message to MIME and sends it via SMTP.

The public interface an entity presents via MERCURY, when no persona is used, is specified in a top level TUNGSTEN object within the entity.

When accessed with a persona, the persona field is actually comprised of two parts - the first being a string naming the persona interface to use, and the rest being any object. The interface for a given persona is found by looking up the persona interface name in the entity's TUNGSTEN state. In the SMTP gateway example, the persona interface name might be "SMTP" and the rest being the actual email address. This is to allow a different actual protocol to be spoken by different personas of the same entity.

A MERCURY interface object within an entity specifies one or more protocols, identified by the CARBON name of the protocol definition document. IODINE and NEON define a few standard entity access protocols, such as a protocol for entities to provide a user interface, or to act as an email inbox.

There is a special protocol called Administration which is partially provided by the system itself; entities cannot override the administration protocol. It provides interfaces to edit the access control lists associated with the MERCURY interfaces exported by an entity under each persona interface name, or the master interface. It provides an interface to obtain the list of references to CHROME modules stored in CARBON within the entity (by examining top level objects that are of the appropriate type) in order to examine the dependencies of an entity, so that all the resources it depends upon can be prefetched for efficiency reasons or if it appears the node is going to have to operate without the benefit of full Internet access for a while. And the administrative protocol also allows the deletion of the entity, and the examination and editing of its TUNGSTEN state.

Entity IDs

Entity IDs are messy things, often quite large (with a list of the IP addresses of all public nodes in the cluster, and the like) and full of numbers. As such, people don't have to deal with them. Instead, entities are generally referred to by a CARBON name; that name, when looked up in the CARBON directory, should return an entity ID object.

Managing mirroring

Each cluster contains one or more logical volumes. There is a compulsory cluster volume which contains the cluster entity, for example. This volume is mirrored on every connected node, since it contains the information required to find other nodes in the cluster containing other volumes. But the cluster administrators may create volumes which are only mirrored on certain groups of nodes.

Example entities

Here are a few examples of how a few common 'things' can be represented as entities.

A document

Be it written text like HTML or a Word document, or something like a spreadsheet or an picture, the concept of a document is that it's a blob of information. Software is needed to view or interact with that information, but the same bit of software can handle any document of the type it's designed for.

Currently, there are a number of formats for documents of each 'type'; HTML, XML+CSS, XML+XSLT, PDF, and Word all compete for roughly the same application domain. And there are a number of applications, each of which can edit one or more different formats.

Well, we'd like to think that there's no need for such a proliferation of formats, if one format could be designed that's extensible enough to be compatible with varying applications. Maybe ARGON will be lucky to be spared this mess, maybe not.

An entity that contains a document in some agreed format will export a protocol named after that format, allowing programmer-level access to the document itself. Eg, a spreadsheet protocol might offer endpoints to get the contents of a cell, set the contents, insert rows, etc. There may well one day be several competing spreadsheet protocols; one would hope not, but it's not a showstopper if this happens.

Inside the entity, this is handled by the spreadsheet data being stored in TUNGSTEN objects, and by the code to provide the public interface to that spreadsheet being referenced from CARBON. Thus, the entity contains no code itself.

The spreadsheet library shared by all such spreadsheet objects would also provide a standard user interface; ideally rather basic, a lowest common denominator. Due to the way NEON user interfacing works, the user interface code running on the workstation will be communicating back to the document entity via the spreadsheet protocol anyway.

However, NEON user interfaces may be configured to react to the presence of the 'spreadsheet' protocol by providing the option of accessing with a different user interface, so the user can still (in effect) choose which spreadsheet application to edit their spreadsheet file with.

Notice that all document editing, however, is handled by communicating changes back to the document entity as you do them; there is no concept of opening a document editor application, loading a document into it, editing it, then saving it. It's all entity oriented. The user interfaces are just CHROME modules demand-loaded to handle providing a front end to a specific entity protocol.

A document has a well defined self contained state; it seems immediately logical that it should be able to expose a snapshot of the state at will. As such, all document-like entities really ought to expose the CARBON protocol to appear as a read only leaf node, with the entire state of the document as its value.

CHROME modules available in CARBON for importing into entities are documents; their read-only state exposed in CARBON is the source code for the module. They provide a "ChromeSourceModule" protocol for editing the source code.

A service

One might write an entity that provides a service, such as a notary public. This would be done by providing a "notary public" protocol with two operations; one that accepts an arbitrary object and returns a signature object, and another that checks a signature by being passed the original object plus the signature, and returning either the date and time it was signed, or an error if the signature is invalid.

Such an entity need not have any internal state, although it might. However, as a bespoke one-off job, it will probably have its own CHROME code to provide the service contained inside it. Of course, it will probably pull shared libraries such as an implementation of a digital signature algorithm by referring to resources in CARBON.

An online shop

An online shop wouldn't be a single entity, although there would probably be a front-end entity offering navigational and user interfacing facilities. Each product would be an entity itself, and an ordering service entity would accept payment information as well as a list of IDs of product entities along with appropriate quantity/style/size information, as appropriate, to place your order.

Ideally, purchasing could be handled by a standard protocol across all or most shops, to enable snazzy tools to scan a number of shops for the best prices, but that may be too much to hope for!

Either way, the ordering service entity should provide a nice user interface for browsing products and adding them to a basket, and making your purchase.

Clusters, nodes, and volumes

Every cluster has a cluster entity that represents the entire cluster. This entity is a repository for metadata about the cluster itself, and would also provide a cluster administration protocol to allow cluster admins to alter the cluster configuration databases, to request the creation of a new cluster key pair, to add and remove nodes, to alter the properties of a node, and so on.

This cluster entity is mirrored to all nodes, to ensure they all have a local copy of the cluster-wide configuration, except that the shared secret keys used within the cluster are not entirely mirrored; there is a key for each trust level within the cluster, and each node only gets mirrors of the keys at its trust level and all those below.

The cluster entity contains within it the WOLFRAM network map of the physical links between nodes. And it contains the ARGON kernel itself, as HYDROGEN source, used to bootstrap a node; update the kernel in the cluster node, and each node will then pick up the new version when it reboots.

Each physical node gets an entity, too. The storage of this entity contains node configuration. This is different from the per-node configuration stored in the cluster entity; the cluster's view of a node will be things like "Can it be trusted?", while a node's own entity will contain stuff that the administrator of that one node can be trusted to change, like hardware settings.

The node entity will also provide SNMP-like instrumentation of node health, for centralised hardware maintenance. And it will provide a list of hardware drivers available on this node, with the ability to configure and access drivers.

Every logical volume in the cluster is represented by an entity, too. It also provides SNMP-like instrumentation to provide statistics, such as estimates of the amount of data contained therein. Backup configuration can be specified here.

Also, the volume entity provides the interface to create new entities within the volume itself.

A device

A physical resource such as a printer would be represented within ARGON as an entity providing a "print" protocol. This protocol would allow querying of the physical capabilities of the device, and submitting a print job. Each job in the queue should be accessible as an entity itself, presumably by the printer entity returning its own enwtity ID with the job queue entry ID in the persona field, to cancel the job, query its status, and so on.

In order to implement this, the entity will contact the node entity for the node with the printer attached, and get in touch with a parallel port driver on it to send the actual byte stream. The printer entity, with its queue of print jobs, need not run on the entity with the parallel port; it could run somewhere with fast reliable disks instead.

A human being

As discussed under IODINE, even users are entities in ARGON. Humans are represented by "User Agent" entities. When a user performs an action upon an entity, it is their user agent that initiates the MERCURY request; so to grant a user a capability, put their user agent entity's ID in an access control list.

Also, the UA entity can be contacted with the protocols discussed under IODINE in order to communicate with the person, find out their public details, and so on.

Creating new entities

To create a new entity, one must contact a volume entity and use the "entity creation" protocol to request creation of a new entity. You give an entity template, listing the top level TUNGSTEN objects to put in the fledgling entity.

Volume entities will generally grant this operation to entities contained within their volume, or to other entities who have been granted explicit access - eg, administrators.

Volume entities may enforce quotas. They may record the original creator of an entity as the entity's "owner". If an entity within the volume creates a new entity, then the new entity will generally inherit the owner of the creating entity, although this can be overriden by an entity that has been granted the ability to do so.

Generally, when a volume is first created, it will contain nothing apart from the volume entity. The volume entity will have been bootstrapped into the new volume in the process of creation, much like node entities or cluster entities are created by the system.

The new volume entity will grant administrative powers to the administrator that created it; he or she can then create entities by hand, or give storage space to other users by creating a "storage space entity" and editing its ACL to give control to the user and marking it as owned by that user in the volume's quota system.

This storage space entity also provides the "entity creation" protocol. The user can then use it to create entities within the volume, and it just proxies the request to the enclosing volume. The storage entity will probably also provide a CARBON namespace to the created entities within for browsing.

Often, an IODINE user agent entity will allow the user to create entities within the same volume as the user agent.

For document-type entities, entity templates will be available in CARBON to create blank document entities with the appropriate references to the document handler code.