Technical Underview

---

Expanded from Ackley (1996)

Though small compared to where it needs to be, version 0.1 is already quite rich---possessing, for example, a fairly well-developed computational and communications model, and, in jargon, a multiple inheritance runtime extensible persistent object-oriented interpreted language with incremental network object and type cache updating, the GUI-based world ccrTk, and the text-only ccrt.

Version 0.1 speaks a scripting and programming language called ccrl that mediates communications between a ccr world and its environment, which consists principally of humans, other ccr worlds, files, and spawned subprocesses. ccrl is more akin to an application scripting language or an object-oriented MUD programming language than to a conventional development language, in that it developed out of and in tandem with ccr. Using ccrl, users can significantly revise the functions of and extend the type system that a ccr world is `born' with.

Rudiments of the object hierarchy

Anything
 |
 |-->Primitives--> Int, Float, Objid, Box, String, List, Vector, Type, etc.
 |
 |-->Root-->Struct--> Method, Reviser, TimeV, Trace, UDPPacket, etc.
      |
      |-->Interprocess--> Challenge, Response, IPHello, IPPing, IPLink, etc.
      |
      |-->Matter--> Channel, UDPSource, UDPSink, etc.
      |    |
      |    |-->Item--> Body, Button, File, Place, Variable, Xproc, etc.
      |    |
      |    |-->Sarq--> Process, Pulse, Quit, SWave, MailRoom, etc.
      |    |    |
      |    |    |-->Link--> Body, Door, Maildrop, Soul
      |    |
      |    |-->Container--> Cave, Place, Vlist
      |    |    |
      |    |    |-->Place-->Space-->Door, Room
      |    |
      |    |-->Force--> ForeignLegion, Reader, ccrSelf, Soul
      |
      |-->Act
           |
           |-->Function--> Bail, OfferNet, CancelNet, Rationalize, etc.
           |    |
           |    |-->OKFunction--> Abs, Not, BinOp, DefType, Eval, RXMatch, 
           |         |            Identify, TypeOf, UDPSend, When, etc.
           |         |
           |         |-->QFunction--> And, Let, If, While, Progn, DefMethod, etc.
           |
           |-->Energy--> TimeOut, LinkProtocol, Now, Rat, MailSend, MailAck, etc.
                |
                |-->GodEnergy--> Unbind, DrawSpace, LogHistory, etc.
                     |
                     |-->ReadEnergy--> Describe, CacheLoad, ReadRefspace, etc.
                     |
                     |-->WriteEnergy
                          |
                          |-->WriteRefspace--> Bind, BindReq, Stub, etc.
	                       |
                               |-->Verb--> Bump, Clear, Click, Close, Enter,
                                    |      Input, Look, Push, Read, Reset,
                                    |      Shove, UDPReceive, etc.
                                    |
                                    |-->Emit--> Beep, Be, Decide, Do, Hail,
                                         |      Have, Pose, Think, etc.
                                         |
                                         |-->Say--> Answer, Ask, Whisper, etc.

Notes on selected object types

Act

The Act is the most general object capable of altering the state of the system -- loosely speaking, an act is like a `message' in traditional object-oriented programming terms, or like a `function invocation frame' in a conventional stack-based programming language, but unlike either, Acts are first-class, allocated objects. (They are not persistent, however; that is what Matter is for.)

Acts fall into two subclasses: Functions and Energy. Functions can be applied to any type of object, whereas energy can only be applied to the object id of a piece of matter. Functions typically complete atomically and return an object as a value, while energy typically runs asynchronously and generates further acts rather than directly returning a value.

Body

A body is capable of moving around, and in particular, it is the only object type allowed through conventional network Doors to thereby move from ccr world to ccr world. A body is linked to a soul, relaying an event stream back to the soul and emitting energy sent from the soul.

ccrSelf

The object :ccr in each ccr world is of type ccrSelf, and it holds information about that world, including its public and private keys (the latter stored encrypted with the user's password, and also marked as a ::Private slot, so the cache management system will never ship it offworld), the version of the code, information about the hardware, and so forth. As of v0.1.88~~, it also includes an optional `PublicHTMLPath' slot to indicate a pathname for writing out status information to the web, as the ccr central key server does in the ccr central status page.

Click

In the ccrTk graphical interface world, certain mouse clicks are (necessarily) visible to the refspace -- for example, to operate a publicly-accessible button in another ccr world. Click energy mediates such actions.

DefMethod

The semantics of a specific ccr world can be altered and extended by locally-defined methods created with DefMethod. Although locally-defined object types (created by Deftype) must be broadcast to the refspace to allow remote ccr worlds to render them properly, locally-defined methods remain resident on and private to the defining machine. The to-date still vaporware network package system is destined to provide a means for transmitting method definitions in a coherent and risks-revealed fashion.

DefType

New object types can be created by subclassing one (or several) existing object types. Created types are persistent and are demand-downloaded to remote ccr worlds as instances of the locally-defined classes enter a remote world's refspace. Foreign type definitions are cached with the data objects of the world that defines them and are not commingled with local data or types. In particular, it is not possible to create a local instance of a foreign type definition.

Door

Along with bodies, doors are the most user-visible type of link. Doors mate up in East-West or North-South pairs, and provide the main spatial mechanism for joining hierarchical structures together laterally.

Energy

Energy objects are acts that are always `at' some piece of matter, though as an energy `propagates', it typically visits several pieces of matter. Loosely speaking, energy divides into two subclasses: `read energy', which propagates entirely within the ccr world in which it was generated (perhaps visiting cached copies of foreign world objects while it does), and `write energy', which propagates through the network physically to visit remote world objects, if any such objects are in the refspace of the source of the energy.

Force

In ccr, only forces are permitted to build objects and perform acts, and the force that created each act is carried with the act as it propagates. The majority of acts within the system require a local force to function; an object of type ForeignLegion exists to perform certain acts on behalf of non-local forces while maintaining usage records.

Interprocess

Below the ordinarily user-visible network interactions, inter-ccr communications are mediated by the exchange of Interprocess objects. Such object transmissions perform functions such as checking that the remote ccr is still alive, and trading high-level usage and latency information (IPPing), ensuring that no extraneous messages have been injected into the communications channel (Challenge and Response), initiating the process connection protocol (IPHello), setting up MailDrops to exchange ccr email msgs (IPLink), and so forth.

Link

Energy generally propagates hierarchically, up from items to the containers that hold them, and down from containers to their contained items, but link objects are the exception. Links cause a point-to-point propagation from one link to its `link mate' whenever an energy object reaches an open link. Crucially, the mate of a link can be in a different ccr world. Via links, individual ccr worlds weave themselves into the fabric of the ccr universe. A Body wandering out on the network is linked one-to-one to a soul which never leaves the homeworld. A door links to another door (on the same or a different world), creating passageways for bodies to move.

Matter

Objects of type matter have network-unique object ids, and are persistent: Once created they remain across program restarts until the connection between the object id and the matter is destroyed via Unbind. As a general design principle, as much as possible of the user-visible program state is stored as matter to provide continuity, including, for example, window positions and sizes, command and focus histories, and error messages.

Objid

An object id is a unique network-wide name for a piece of matter, including the IP address and port number of the ccr world that owns the name.

OfferNet

The offernet command is built on top of the ccr email system, and is used to offer a doorway to a specific other ccr world. Both worlds must explicitly issue an offernet naming the same door pairing, but either world can unilaterally issue a cancelnet command to destroy the link.

Pose

Named in homage to the great lineages of MUD development, pose energy propagates an arbitrary descriptive phrase to refer to the soul that generated it. As of ccr v0.1.88~~, pose text can include HTML2.0 tags.

Process

The process object represents one ccr world's knowledge of another ccr world. The `Known Worlds' entry in ccr central status page, for example, is the count of process objects in that world that have public keys stored with them. In addition to maintaining static information like the remote world IP address and port number, the process also maintains incremental information such as the total communications traffic between the worlds, and dynamic information such as the links that are currently open between the two worlds.

Rationalize

In the land of distributed computation, there are ever so many ways to screw up! The perfect ordered domino trails of Von Neumann machine computation are, at best, a hopelessly inefficient approach in large-scale distributed systems. Recognizing this, ccr expects that every type of object within the system will provide a method for the `Rat' energy, and when that method is invoked the object will perform a self-consistency check and take whatever steps are necessary to bring the object to a consistent state, perhaps propagating Rats to touching objects in the process.

Although, in principle, there is always the possibility of `runaway Rat loops' between objects -- ``I say this, you fix yourself!'' ``No, I say this, you fix yourself''... -- in practice so far it has proved relatively easy to find one or more natural `ground states' for object collections to terminate Rat propagations. For example, a `soft ground state' for a mated pair of Links is the link is closed; a `hard ground state' is the link is disconnected.

Rationalize repeatedly propagates Rat energy to each object in the local world until all objects report no changes, or a specified number of passes have been performed. Rationalize is performed automatically at system start up, but can be requested while the system is running, as sort of an `online fsck'. When run online, it is possible that occasionally an object will be caught midway through a protocol exchange and will appear to be inconsistent to the Rat method, and the Rat method will rationalize the object, and whatever was in progress will likely fail to perform as desired. But so what? The system is designed to expect things to screw up nearly arbitrarily, and to keep on functioning anyway.

ReadRefspace

Since local ccr worlds keep cached copies of accessible objects from remote worlds, there is a natural distinction between acts that only examine data, and acts that intend to change data, since the latter acts must actually reach the world that owns the data to have a chance of affecting it. ReadRefspace energy access the local cache and perform no network traffic, and are used for tasks such as drawing the refspace in the ccrTk view window, finding the relative position of an object in the refspace, or simply enumerating the refspace for some other purpose.

Room

The basic workaday container that users are most familiar with. Because it is a Container, it can hold Items; because it is a Space, it has two-dimensional extent and constrains its contents to a bounded region.

Say

The basic means of talking, as well as the base class for more specific modes of talking such as whispering, exclaiming, answering, and so forth. The ccrl parser translates all input lines that do not begin with `[' into some kind of a Say: An Exclaim if the last character is `!', an Ask if the last character is `?', and a plain Say otherwise. This has the side-effect that a leading space can be viewed as a comment character in ccrl program text, causing ccr to speak the `comments', but do nothing else with them, as the program text is read.

Soul

The `invisible end' of a body link. The soul is in charge of parsing keyboard and pointer events from the god of the ccr world, drawing the soul's refspace in the view window (in ccrTk), shipping emitted energy to the body, and `unparsing' the event stream received from the body into the soul's ongoing ccr life story.

A subtlety often confusing to new users of ccrTk is that the image that is displayed in the view window at the location of a body is actually stored on the soul, not on the body. This apparently poetic `face is the mirror of the soul' design decision actually arises from basic and concrete concerns: Once the body goes off the home world, the home world god essentially loses write access to the body, while the god of the world the body visits essentially gains total power over it. Placing the `face' on the soul allows the soul owner to control it directly, rather than having to play kind of `Mother may I smile' games with the current owner of the body. More experienced ccr gods see bodies basically as place-holders indicating that its associated soul is in the refspace.

Verb

Many of the basic actions that users --- and ccr worlds themselves --- perform are verbs, with a `object' indicating what is to be affected, a `subject' saying who requested the action, a `tense' indicating whether the verb is currently a `request' (present tense) or an `event' (past tense), and a `result' describing how things turned out (if the verb is an event). A Verb such as Say propagates from the soul to the body in the present tense. Once it reaches the body (assuming it does), the verb `succeeds' and a past tense copy of the verb is repropagated from the body. It is (almost entirely) the stream of past tense verbs arriving at the soul that comprises the ccr life story of that soul.

WriteRefspace

Unlike ReadRefspace energy, which can complete locally using cached copies of remote objects, WriteRefspace energy are designed to side-effect the state of the ccr universe in some way, and consequently they must propagate through the network to reach their targets. Just about everything that `does something', in a simple-minded sense, is WriteRefspace energy. Note that in complex refspaces (e.g., multiple netdoors off a single room), a WriteRefspace object may actually propagate through multiple machines before having its final effect.

References

Ackley, D. H. (1996, to appear).

ccr: A Network of Worlds for Research. In Artificial Life V, MIT Press.