This document describes the basic concepts used in the omixed server. It should be read by anyone planning on interacting with an omixed server either via the programmatic API or the Admin Console tool.
An omixed resource is a database which has been populated using a particular schema. A single omixed server instance can manage any number of resources simultaneously.
The omixed server also manages a collection of user accounts. Accounts can be given permission to connect to zero or more of the resources managed by the server.
Resources are filled with items. Each item is of a specific type determined by the schema. Every item has an owner and is in an access group which determines how other users can interact with it.
For administrative ease, users can be aggregated into groups. Permissions and policy decisions can be then be granted to these groups of users.
An omixed server hosts a number of resources. A resource is a structured collection of data, files, forum messages and suchlike. A resource is essentially equivalent to the relational database that implements it, but the term resource is favoured as it is has fewer technical connotations for end users.
User accounts are independant of any particular resource. Users can be given permission to access any subset of the resources being managed by an omixed server.
Resources and user accounts are managed via the Admin Console tool.
When a user connects to a resource, a session is created. A session is identified using a session ID which is allocated by the server. This ID is then used to authenticate all subsequent interactions with the server until the session is closed.
Each resource is defined by its schema. The schema is the data model that the resource contains. At the relational database level, the schema is mapped to the collection of tables and their fields. Each resource is associated with exactly one schema (although a resource can exist without a schema, it is not possible for users to interact with that resource until it has been initialised with a schema). This is typically done using the Admin Console tool, although a Web service API exists enabling any application to load schemata.
Schemata are represented in using an XML format which can either be hand-crafted in a text editor or XML editor, or can generated interactively using the Schema Designer tool.
A more detailed description of schemata as used in omixed can be found in the Schema Designer documentation.
To both avoid the somewhat overloaded terminology of relational databases and object-oriented programing, and to avoid overwhelming end users with technical jargon, omixed consciously avoids the terms "table", "class", "object" and "instance". Instead, it refers to items and item types. An item type (a.k.a. class or database table) is a template for instantiating items (a.k.a. objects or database rows).
Items have a unique itemID which identifies where they are stored, their type, their owner and their name. An itemID is a composite string made of five components:
The omixedDomain component identifies a particular omixed server. The omixedDomain should be chosen so that it is unique. Note that the omixedDomain does not have to match the internet domain name of the machine hosting the omixed server. Eventually, a distributed registry of omixedDomain identifiers will be available which will enable these identifiers to be mapped to specific IP addresses.
The resource component specifies a resource available at the chosen omixedDomain.
The itemType component is the name of an item type which is defined in the schema loaded into the specified resource.
The itemOwner is the name of the user who owns the item. This name is guaranteed to match a user account for the specified resource.
Finally, the itemName is the name of the item itself.
Within a single item type, item names do not have to be unique, but any given user must use unique item names within each item type. In this way, every itemID on a particular omixed domain is guaranteed to be unique.
The / delimiter is used to separate the components of the itemID and it must not appear in any of the first four components (indeed,, there is no method of escaping this character). However, it can be used in the itemName component as it has been observered that / is quite regularly used in naming things, for example "miles/hour" or "alpha/beta/gamma".
Each item has an owner and is in an access group. The access group for an item determines what operations each user can perform on that item. For example, some users might be able to see the item, but not edit it, whereas the item might not even be visible to some other users.
There are two fundamental access groups which are always defined; 'public' and 'private'. Items in the 'private' access group will only be visible to the user who owns them, whereas items in the 'public' access group are visible to all users.
As well as whether the item is visible or not, the access group also determines whether the item can be edited or deleted by specific users. For example, unless specific permissions are assigned, only the owner of an item can edit or delete it, even if it is in the 'public' access group.
An item can be moved between access groups at any time, as long as the user trying to move it has sufficient permission to do so.
It is possible to create any number of access groups in the spectrum between public and private. Each access group specifies the set of users that can see, modify or delete items in that group. Creation and manipulation of access groups can be done using the Admin Console tool.