The configuration manager is a new service introduced in Companion 8.5 and ATOS/CX 12.1 which stores system and application settings to ensure continuity during updates and resets. In Companion 8.5, this facility is only used by the system to allow library hibernation and does not extend to every possible option settable by users.

As explained in Best practices for 8.5 application development, settings are accessed through a dot-separated naming convention and can be nested arbitrarily, e.g. a.b.c.d.

The conventional terminology is as follows:

• The name of a setting is a "key," for example a.b.c.d and a.b are both valid keys.
• The actual data stored is a key's "value." Internally these are always recorded as strings, so floating-point values may not be recorded exactly.
• A "segment" is one part of a key, for example a.b.c.d consists of the segments a, b, c, and d.
• A "prefix" is a key name which matches the leftmost segments of one or more other keys which are not identical to it. For example, a.b.c.d is not a prefix of itself, but a.b.c, a and a.b are prefixes of a.b.c.d.
• A "parent key" is the immediate prefix of a given key that exists in the configuration store. a.b.c is the parent key of a.b.c.d.
• An "ancestor key" is any prefix of a given key. This includes the parent key.
• A "child key" or "sub-key" is one that has a given key as its parent. a.b.c.d is a child of a.b.c.
• A "descendant key" is one that has a given key as its ancestor. a.b.c.d is a descendant of a.b.
• A "hive" is a key with only one segment, for example a.
• A "branch" is a key and all of its descendants.
• A "leaf" is a key with no descendants.

Unlike typical directory systems, keys may have values even if they have descendants.

To retrieve the unit's model, send SETTING_GET with the string parameter equal to the key you wish to access, in this case boot.model. The answer will be returned with SETTING_VALUE, including the key, for example: boot.model SXD

Optionally you may supply a randomly-generated UUID parameter, which will be returned. This is similar to the use of query UUIDs for data server retrieval and HTTP events in LSL. Scripts should always parse SETTING_VALUE messages for which no UUID is supplied.

The following messages are used to interact with the configuration manager:

Finally, multiple settings may be interacted with simultaneously. Providing multiple string parameters separated by linebreaks will treat them as independent commands; in the case of SETTING_GET, the returned values are separated by multiple lines. Additionally, SETTING_GET and SETTING_DELETE both operate on whole branches, so that getting a hive will return all of the keys and values within. As a result of this format, linebreaks cannot be stored in settings; escape them first.

Below are the keys and hives used by Companion 8.5.0. For convenience, the types are specified after a colon, e.g. the data in access.self is expected to be of type bool, even though the value is actually stored as a string. The types are:

• bool: Boolean value (0 or 1)
• uint: Unsigned (non-negative) integer
• str: Unconstrained string (no linebreaks)
• float: Floating point number
• n-float: n floats separated by spaces, usually n = 3 and this encodes a vector
• word: String with no spaces

If a limited range is applicable, it is indicated in parentheses after the type.

access
	local:uint (0-3)
	remote:uint (0-3)
	self:bool

boot
	model:str
	vendor:str
	authority:str
	name:str
	prefix:str
	path:str
	serial:uint
	color:3-float (0.0-1.0)
	
	verbosity:uint (0-2)
	bootstyle:uint (0-7)

profile
	(variable uints; defaults:
		full:uint
		sleep:uint
		idle:uint
		eco:uint
		listen:uint
		emergency:uint
	)

domain
	prefix:str
	name:word

policy
	users:bool
	apparel:bool
	radio:uint (0-2)
	subsystems:bool
	persona:bool
	vox:bool
	curfew:bool
	curfew-time:str
	home:str "/" int "/" int "/" int

performer
	color:3-float (0.0-1.0)
	%:int
	@:float
	$:str