Contexts

Top  Previous  Next

One of the key concepts introduced in this manual is the context. A context is a logical "container" for data related to some object or hardware device. It also provides methods for manipulating this data and monitoring the object's state. For example, LinkServer internally works with contexts that correspond to Devices. It creates a "Device context", and this context is used to monitor and change Device settings, view its events etc.

Context Tree

Almost all data managed by LinkServer is represented by contexts. Contexts are organized into a hierarchical structure called a context tree. Every installation of LinkServer contains  a single context tree. This tree is dynamic, so contexts can be added and removed from it during normal server operation.

All contexts available in LinkServer are described in Context Reference.

Context Naming

Every context has a name. This is a string that may contain only letters, numbers and underscore character ("_"). For example, the context for the admin user is called "admin".

As mentioned above, the context tree is hierarchical, and every context in the tree may be addressed using its context path. The context path may also referred as the context's full name. The path consists of one or more context names separated by dot (".") characters.

Example 1: the users context corresponds to all users in the system. It provides some generic user-related data and operations like "New User Account Registration" operation etc.

Example 2: the users.admin.deviceservers.ds1 context (shown here in its full name) corresponds to a Device Server called ds1 registered under the admin user. This context provides access to the settings of Device Server and related operations, e.g. "Reboot Device Server" etc.

The context tree "grows" from a so-called root context. The root context is unique in that its name is "" (empty string).

One more term related to contexts in the tree is parent-child relationship. Every context in a tree except for the root context has a parent context. Also, every context may have zero or more children. For example, users.admin is a child context for users (which makes users a parent context, obviously...).

Context paths may be absolute (i.e. resolved from the context tree root) or relative (i.e. resolved from some other context). Relative paths start with a dot (".") character.

Sometimes the user can specify the name of the context. For example, when creating a new Device Server account, the name of the Device Server Account is used as the context name.

Context Descriptions

A "Description" is a user-friendly name for a context. It is used to refer to this context all throughout the user interface. For example, the context description of the context device_plugins_config is "Device Plugins Global Configuration".

Sometimes the user may specify the description manually, such as when creating a new Favourite. In this case, the user-specified description will be used to refer to the favourite in the user interface.

Having separate properties for the name and the description allows AggreGate to maintain one name for a context internally, while allowing maximum user friendliness by using a simple description. In addition, changing the description for an object will smoothly alter its appearance in the GUI without "breaking" it (because internally, it will still have the same name).

Context Types

The "Context Type" property of a context helps AggreGate decide if the same operations may be applied to different contexts, such as properties between them. For example, you can copy the properties of a Device Server to another Device Server, but it would be meaningless to try and copy the properties of that Device Server to an Alert context.

Therefore, AggreGate only allows copying context properties between contexts (also known as "replication") when the context type is identical between two contexts.

Context type is a string that may contain only letters, numbers and underscore character ("_").

Context Entities

Every context contains a number of so-called entities. There are three types of entities:

Variables (Properties) that allow to view or change some data associated with a context.
Functions used to execute some actions associated with a context.
Events helping to see if something happens in a context.

Context States and Icons

Every context has an icon that is used for its visual representation in LinkServer user interfaces (like AggreGate Client).

Some contexts may have different states. For example, the context for a hardware device may have two states: "online" and "offline". Every state has a different icon associated with it.

Context Permissions

Every context has a permission level. For a user to access the context, they must have an effective permission level for this context higher or equal than the level of the context itself. For example, if a context's permission level is User and one's effective level for this context is None, he won't be permitted to access the context.