A core design goal of KOS is configurability. Whether setting user-visible settings such as cup sizes, internal properties such as timeouts and delays, or environmental settings such as endpoints, KOS provides the core infrastructure to handle most configuration needs. Configuration support is comprehensive and feature-rich, so it’s helpful to understand the general capabilities built into KOS before building alternate configuration infrastructure.

Configuration as data objects

While configurations can be defined in several ways, developers consume configuration data as simple Java objects. A configurable component creates a Java bean with properties to hold the configuration values, and KOS will automatically populate the bean’s properties and update it in real time as configurations change. Developers read the values directly from these simple Java beans and receive lifecycle events when changes are made. There is no need to parse files, monitor for changes, and so on, as KOS handles all of this automatically. Configuration beans can even be complex graphs of objects, and KOS will automatically manage these beans, identifying which properties change along with both previous and new values, allowing developers to react to configuration changes in real-time with very granular precision.

Configuration metadata

The KOS configuration system allows developers to provide metadata about individual configuration properties via Java annotations. This data is then used by KOS tooling and SDKs to automate many common tasks, including:

• Descriptions: By annotating configuration properties with a description, the KOS Studio configuration editor can show descriptions for each property and allow users to search on both the property name and the descriptions. For projects with hundreds of configuration settings, this drastically simplifies finding properties, checking their values, and understanding their purpose.
• Format: It is possible to provide format hints for individual configuration properties. This is user-extensible and generally indicates the use or units of a property. For example, a property tagged with a format of seconds or milliseconds is understood to be time-based, while a format of grams indicates a measurement of mass. The UI SDK uses this information to auto-format and auto-convert units without requiring developers to get involved. Consider a time stored in milliseconds to allow for very short timeouts during unit testing, but it should generally be displayed and edited in seconds in the product UI. Developers must indicate the desired units to the UI, and KOS will handle all transformations automatically. The same is true of units of measure. KOS will utilize the unit system defined for the selected region and automatically convert units with a correct number of decimal places.
• Options: Consider a configuration property that represents the volume of a cup. While this may be stored in milliliters and displayed in ounces, there may need to be some practical constraints on the options shown to the user. For example, there may be a minimum and maximum cup size that the UI should show, and the value entered may need to be a whole number of ounces. Metadata on a configuration property can be used to pass along metadata about how the UI should render the editor on screen and how to validate the values entered without any additional developer input. This metadata can even be overridden by other configuration data, allowing shared code to have different max cup sizes on different platforms without needing to write code.

Default values and overrides

The configuration system in KOS understands the difference between default and override values, and there are APIs available to detect when a value is not the default value. This can be used to show users which values they’ve changed to make restoring to defaults easier.

KOS computes default values from a stack of configuration sources, ranging from XML files to custom code. These layers can be dynamically inserted and removed, providing an easy way to bulk change default values based on internal state. For example, while in test mode, a configuration layer can be injected that configures all ecosystem endpoints to your test environment. Switching modes remove this layer, and all endpoints are reverted to production settings.

This infrastructure is well aligned to compliance checks as it provides rich information about the current value, when it was last changed, whether it differs from defaults, etc.

Multi-node capable

As KOS is a distributed operating system, potentially operating on multiple nodes in a single device, the configuration system is entirely distributed and scoped. This means configurations can be set globally, by nodeType, or individual nodes. Settings can be modified on any node and replicated in real time throughout the device. The primary node has a unified view of the entire device, allowing all device configuration data to be viewed in a single location. This also allows agents to access all configuration data on the entire device while only needing to run on the device’s primary node.