This short web page describes the essence of an approach to all future data storing requirements. All data is stored in tuples, either as further nested tuples or as simple leaf constants that have a few, restricted forms.

Requirement

Operating systems have, up until now, provided primitives for file access that are separate from those provided for network remote procedure call. Increasingly, this separation is unhelpful. When looking up an item of information, such as checking the permissions granted by a license, the application program has no interest in whether the details are retrieved from a local file or a remote resource. Tuple space computation is a new model of universal computation that has a sound and elegant theoretical basis, yet which may be efficiently implemented on today's computers and networks and incrementally phased in.

Tuple Definition

A tuple consists of an unordered collection of fields that are each tag name/value pairs where the tag names are different constants. The values are either leaf constants or other tuples. A given tuple may be stored in multiple other tuples and/or in multiple fields of the same, parent tuple. A tuple may not store itself, directly or indirectly, and hence all tuples are part of a global tree that has its root in a unique global tuple. Tuple computation uses the imperative programming paradigm, where a data value is stored at specific instance in time and that value is retained for those who observe it until it is next changed with another store.

Leaf Constants

In order for a high-level language that deals with tuple to have a uniform semantics, it is convenient if functions and function closures can be stored as values in a tuple field. These values may be supported and understood within that HLL, but it would be an extension to this TSC architecture to allow these values outside of the language environment.

Primitive Operations

The three main primitive operations allowed on a tuple are to list the tag names, to read the value stored under a given tag or to store a new value under a tag. Where a store operation refers to a tag name that does not previously exist, the tuple is extended with a new field of that tag name. Two other primitive operations are provided, described below: vstore and tread.

Garbage Collection

The tag value $REFCOUNT is reserved by the substrate. A tuples uses this tag as a reference count, maintained by the substrate, that indicates how many tuples it is stored inside. Users of tuples must ensure that all wanted tuples are members of at least one parent at all times. When this reference count is zero, the tuple may no longer be accessed and its resources reclaimed. An exception is the global tuple, that has no reference count field. In the real world, the tag names in the global tuple must be URI strings, but this is unimportant in toy demonstrations.

Views

A tuple may be restricted by a view, where only certain of the fields are reported by the list operation. This is useful for various purposes, including security using long, obscure names for tag values. A restricted view is created using a `vstore' operation to insert the tuple in its parent tuple. Only the fields present in the tuple at the time it was stored using vstore are reported when the list operation is applied to the tuple when it is accessed through that parent. Also, new fields may not be added.

The tag value $RO is reserved by the substrate. It denotes a read-only field. A read only view of a subtree of the tuple space arises whenever it is accessed via an RO tag.

The reference count field retrieved in a view of a tuple is the reference count for that view. The reference count in a viewed tuple includes at least one for each distinct view taken, but may account for less than the full sum of the number of references to all views.

Archiving and Revision Control

A framework for access to archiving and backup of the global tuple space is provided using the `tread' timed read primitive. This primitive operates on a tuple, a tag value and a timedate to retrieve a view of the contents of a field on a given time and date in the past. The timedate parameter must always be no later than that used to read the parent tuple because the archiving system is only required to remember the past of a given version of a tuple and not its future. Using tread, the normal read operation need not be primitive since it is identical to a tread with the timedate parameter set to the current time and date. Whether and when backups are taken will vary from one part of the global tuple space to another.

Discussion

Schemas

Large parts of the global tuple space will contain structured data stored under schemas. It is not the role of the TSC substrate to enforce schemas.

Relational View and Primary Key

A tuple may be considered to be a record in a relational database whose primary key is the tag name of the field it is stored under in its parent tuple.

XML Interface

Any part of the global tuple space can be converted to XML. There are a number of possible conversions. A recommended method is to list each field in turn as an XML subtree with name TSC with attribute `tn' set to the field tag name.

Since fields in tuples do not have any ordering, an arbitrary order must be selected when converting to XML.

HTTP Access

SML Datatype

A suitable datatype for the global tuple space can be given as the following disjoint union:

datatype T_t =
	  T of (string * T_t ref) list ref
|         Tls of string
|         Tdt of datetime_t
|         Tcredit of credit_t

;

Access control information is not held in the tuple but is instead embedded in the handle used for reference. Reference counts and an efficient way of representing views are added in practice.