An ARGON cluster is a bunch of nodes in the "real world", and a bunch of entities in the "virtual world".
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 as individual nodes; unless initial installations or hardware upgrades are involved, operations like upgrading software will be performed on the whole cluster.
The cluster cooperates to create the illusion of having one giant shared persistent mass storage full 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 automatically - and code.
Entities publish information to each other, including entities in other clusters. The navigational "tree" of entities is also built from published parent/child relationships, along with information about entities such as their names.
The software that specifies an entity's behaviour can be stored directly inside the entity, or it can refer to published modules of shared code.
Each entity has an ID, which consists of the cluster's ID, plus an entity number, and an optional persona field.
Entity IDs are messy things, often quite large (with a list of the IP addresses of all public nodes being part of the cluster ID, for example) and full of numberic data such as cryptographic keys and hashes.
As such, people don't have to deal with them. Instead, entities are generally referred to by a name, which is a path within the "navigational tree" made up from information published by entities. A name can be looked up to find the entity ID by examining the published information for each entity in the path, starting from a root entity whose ID is configured into the cluster.
The optional persona field in an entity ID 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 to get back 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 appears as a place to which objects can be sent, with an implementation that actually converts the message to MIME and sends it via SMTP.
The important thing to know is that personas let an infinite number of "virtual" entities exist, while only one "real" entity needs to actually be created in the cluster. The entity just presents a different persona when accessed through a different ID.
Here are a few examples of how a few common 'things' can be represented as entities.
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 the document data as published knowledge, and will provide an interface to allow programmer-level access to updating the document itself. Eg, a spreadsheet protocol might offer endpoints to set the contents of a cell, 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.
The spreadsheet entity wouldn't contain any actual source code for these operations - it would just refer to an entity which publishes the spreadsheet source code as shared modules.
The spreadsheet module shared by all such spreadsheet objects would also provide a standard user interface; ideally rather basic, a lowest common denominator.
However, ARGON 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.
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 source 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 published shared modules.
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.
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 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 using the standard "object push" protocol which lets people send things to it. Each job in the queue should be accessible as an entity itself, presumably by the printer entity returning its own entity ID with the job queue entry ID in the persona field; this virtual entity publishes job information, and provides an interface to cancel the job (through the standard administrative interface to delete an entity), pause it, resume it, and so on.
A human being
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 uses the interface; so to grant a user a capability, put their user agent entity's ID in an access control list.
As well as acting for the user in the virtual world of entities, the user agent also publishes information about the user, and provides interfaces to interact with them. Think of it as being like your email address, blog, or social networking profile.
Programs and Applications
As is probably already evident, ARGON's model of entities is more like the Web than like a desktop environment or mobile device with installed applications.
However, there is something that works a bit like a desktop environment; your user agent. When you "log in" to an ARGON human-interface device, your user agent is given access to the device's capabilities to present you with a user interface. What that user interface is entirely depends on your user agent - you get to choose it. Its responsibility is to let you browse the information published by entities, which includes navigating the navigational structure they provide, and to interact with user interfaces provided by entities; entities provide programmer-level APIs, but they can also publish a "user interface" that is downloaded to your human-interface device and run there, where it can use the API to talk to the entity while providing a nice interface to you. There's a standard protocol for this, called NEON, providing a suite of user interface models from touch screens and 3D worlds to command lines.
However, your user agent can let you use your own user interfaces instead. If you install a better spreadsheet "app" into your user agent, then it will override the default one provided by spreadsheets you encounter.
Also, your user agent can manage data for you inside itself. For a start, it manages information about you that is published to others, and you will also be able to install apps into it that manage that for you. Secondly, it provides APIs to let other people contact you through it, such as sending you things, requesting to book a meeting with you, requesting real-time chat, and so on. Those are all provided by apps you install into your user agent.
Finally, a user agent might contain a load of entirely private information, never published or made accessible via an API, managed entirely by an internal app, such as your phone book.
These apps, of course, are just shared source code modules published somewhere, plus some wrapper information declaring them as installable user-agent apps.