This page introduces concepts and terms the reader need to be familiar with before one reads module specifications.
The text assumes the reader has basic knowledge about computers.
Kueea System is a peer-to-peer operating system. This means that for the system to function there needs to be a network, although this network may be composed of only one peer.
The term peer or host refer to a device that is connected to other devices with some kind of network technology. Ethernet is an example of such a technology.
Throughout the pages the term network refers specifically to a network of devices, which all execute some implementation of Kueea System.
Each such network is defined by the set of host which compose it, as well as its trust anchor, which is a set of entities that every peer in the network trusts by default.
Networks that have the same set of entities in their trust anchors are compatible and their resources may thus be merged together.
The goal of Kueea System is a state where every peer on the Internet agrees on a common trust anchor, i.e. every peer on the Internet is part of one big Kueea System network.
Realistically, this will probably never happen.
One host may be a peer in multiple networks at the same time. Which network is to be considered is based on a data packet's source address.
Resources in Kueea System are stored in a global graph. This means that at the low level there are no files nor directories. If one needs, one may compose a tree from the nodes of this graph.
Resources are either device-independent, in which case their identifiers do not take device or host identifiers into account; or they are device-specific, in which case the host needs to be specified. Device-specific resources are generally limited to actual physical devices.
Resources called kueea are entities on behalf of which tasks are executed. They are conceptually not users, but something closer to pseudo-users on UNIX systems. User resources are sets of kueea credentials and are stored outside the system.
When someone wants to use the system, the person points the system to its user resource. This user resource is something one carries with oneself. It could be a pendrive or some other removable storage device. It should never be stored on a publicly accessible device.
Once the system has access to the user resource, the user is asked to provide the system necessary information required to access kueea credentials stored therein. When the system successfully accesses the credentials, it then asks the user to choose under which kueea tasks are to be executed.
The shell is designed so that users may freely switch between their kueea within the same session. Some tasks may require contacting other deivces. In this scenario, the task will identify itself as the kueea on behalf of which the task was executed.
Kueea are globally unique resources. They are generated independently of the system and then registered with a network in order to be recognized. Users themselves are the sole authoritative source of information about their kueea, although there is a third-party trust anchor involved. No host may act on behalf of any kueaa unless explicitly allowed by the user.
Access control in Kueea System is decentralized and based on network policy. A host determines whether a kueea has access to a resource based on information coming from the network it is a part of.
Public metadata is always transferred before the data, so that a host may verify access before requesting the data proper. Hosts that requests data on behalf of kueea that do not have rights to said data are mailicious and are to be banned by every peer in a network.
Know your peers or follow the policy.
There is only one fundamental type in a Kueea System: an octet. An octet is an integer in the range 0–255.
System memory is an array of octets. If a device physically store more than eight bits per byte, bits 8 and more significant are ignored by the system. Devices that store less than eight bits per position are not supported.
Types are defined by specifying their memory representation. They are independent of processor architecture.
A definition of a type is called a class. Classes are identified by a pair of a UUID and 32-bit revision number. Higher revisions are backward-compatible with previous revisions. Higher revisions generally extend the representation by appending members.
Classes may implement interfaces, which are sets of functions. Interfaces are identified by a UUID and length of the structure.
Instances of a class are called objects.
Each object created in the system has an associated class descriptor, which is a data object containing class information. It contains class identification data and references to implementations of functions defined by interfaces that the class implements.
Object memory is managed by the system, not by a task. Tasks request memory for an objects, construct it and then indicate to the the system that they do not need it anymore. Tasks do not destruct objects – the system does. It is because other tasks may be using the object.
Tasks may gain access to objects created by other tasks. This is the core functionality of Kueea System. Tasks may call functions in separate, distinct tasks, which at the start gain access to necessary objects.
The system is designed so that code for executing a function in the same context and in a separate context is the same. The build system determines whether functions are external or not.
Modules are collections of symbols.
Modules are identified by a UUID and 32-bit revision number. Higher revisions are always backward compatible with previous revisions.
The identifier acts as a name space for the underlying symbols. Symbols are either objects, functions or messages.
A module implementation may be composed of implementations of several modules.
Module implementations are identified by a 64-bit implementation identifier, also called a build identifier. Generally, a symbol reference should not refer to the build identifier, but there are cases when such a reference is desired.