KOS is designed from the ground up to be a collaborative environment, envisioning applications from various partners working together to accelerate the delivery of exceptional products. This is reflected in the KOS assembly vs. build architecture and the KOS Studio marketplace. While this can be a huge accelerator, it does introduce several new challenges compared to building large monolithic code bases, particularly around naming global entities, such as application IDs.

The KOS ecosystem doesn’t provide global registries for names and IDs, leaving these choices to individual developers. This means multiple developers can pick names that collide when their works are combined onto the same device. To minimize the chances of this occurring, KOS uses a combination of namespacing and naming conventions.

Naming things

As with any other development environment, most things a developer needs to name are local in scope, meaning the name is entirely up to the developer. This is generally true for naming classes, methods, variables, etc. However, some parts of KOS are shared, so some care is required when naming them. For example, every KOS application must have a unique ID. In these cases, developers should use namespaces to isolate their names from other organizations. For example, rather than use an application id of “deviceAgent”, use an id with a namespace such as “tccc.deviceMgmt.agent”. By including the organization at the front of the namespace, any possible collisions are restricted to your organization.

Another shared area is JSON descriptor files. Every KAB file can have a descriptor.json file, which can include additional metadata about the contents of the KAB. Developers are free to put additional data in these files, but again, they should be careful to namespace their data. All KOS standard data is always in a “kos” object within the descriptor. As KOS owns these, their formats and functions are fixed. Developers are free to add another top-level object using their organization name to include their specific data.

By taking care when naming entities that are part of shared resources, developers can ensure that their work can integrate seamlessly with the work of other developers from other organizations.

Namespaces

KOS is a dynamic runtime that allows any number of applications to work together collaboratively. Unlike mobile operating systems, where applications are inherently untrusted and sandboxed, KOS allows applications to work together, even sharing classes for easy integration. However, this can introduce some complexity when working with shared resources. For example, where can applications safely write to disk without concern that other applications may overwrite their data? Filesystems, URLs, and VFS paths are all shared resources in KOS that are subject to collisions if not carefully managed.

The solution to this problem is allowing KOS to namespace shared resources for the developer automatically. The most common method of namespacing shared resources is via application ID. For example, every application has a dedicated area on disk, which includes the application ID in the path. All endpoints exposed by the webserver for an application contain the application ID in the URL, and so on. This means there are two critical aspects to selecting an application ID:

• Don’t include unsafe characters in your application ID for filesystems or URLs. For example, don’t include slashes or unusual characters in your ID.
• Pick your application ID carefully, as it will be visible in path names and URLs. If you change your application ID later on, anyone integrating with your application via endpoints may need to change their code to match.

Careful consideration of shared resources in KOS allows developers to have the freedom to develop without central authorities while still ensuring easy integration with the works of others.