(Classic) Personal Cloud OS Services

Cloud OS is part of the classic engine. The new Node pico engine

Personal Cloud OS Services provide a usable abstraction of the CloudOS kernel API to developers. This document is a roadmap to various CloudOS services.

CloudOS is a work in progress and as such much of the information in this document is subject to change.

As a result, CloudOS is better suited for some projects that others (especially because of it's incomplete security model). If in doubt, ask about the suitability for your project.

Preliminaries

Understanding and programming CloudOS requires some understanding of KRL (Kinetic Rule Language). The manual is available online.

The Live Web book is a better introduction than the manual.

KRL runs in an event-based rules engine called KRE. KRE (Kinetic Rules Engine) is an open source event processing engine. KRE is unique because it has identity built into the core of the system and events are raised for a specific entity. Rules are scheduled based on a combination of the event and the rulesets that the entity has installed. KRE also supports entity specific persistent storage. The combination of these features gives rise to entity-specific, persistent computational objects, or picos. Picos are a salient feature of KRE. Picos are the virtual machines that the CloudOS runs on.

CloudOS is an open source project hosted on Github.

Status of Open Source Project

The status of the open source project is immature. Kynetx recently decided to open source CloudOS and there are still keys that need to be redacted before we can make the code available. We are working to fix this.

Events

CloudOS operates against events that can be encoded in HTTP, SMTP, and other transport protocols. The most important things to know for understanding the evented APIs in CloudOS is event expressions (eventexes).

The CloudOS API depends on the KRE (Kinetic Rule Engine) meta APIs Sky Events and Sky Cloud. I say "meta API" because these protocols don't describe a specific API but rather show a pattern for how events and HTTP (REST) calls can be made to the underlying system. What happens (semantics) depends on the particular rulesets that the owner of the pico has installed.

All picos running CloudOS have a set of services installed. Each of these define events and HTTP calls that application programmers can use. Services are written in KRL, but they have a specific architecture and usage pattern than sets them apart from other KRL programs. Right now, the following services are installed by default:

CloudOS

The CloudOS service manages pico creation, destruction, and interaction. Provides protocol interactions for pico-to-pico subscription (whereby channel identifiers are exchanged). CloudOS service is described in these documents:

Personal Data Service

The Personal Data Service (PDS) manages personal data. Every application has access to the PDS. The API is not yet complete. In particular the design should do a better job of defining common data elements and versioning them. We are currently working on a project called PDSx with that goal in mind. The documentation is similarly incomplete. The best documentation right now is the CloudOS.js README.

Notifications

Intra-pico and inter-pico notifications are supported by the notification service. Notifications are shown to the user in a variety of ways, including email and SMS. Notifications provide applications programmers with a consistent way to interact with users. Described here:

CloudUI

The CloudUI service is responsible for painting the CloudOS dashboard as well as managing application configuration in a consistent way. No documentation is available at present. But there are cookbook examples for using it:

Authorization and Security

In addition to these core services any ruleset in KRL can define a module that becomes available as a Sky Cloud API to authenticated applications. Authentication is via OAuth 2.0 as described here.

The Sky Cloud API documentation (referenced earlier) also has important information about authorization via OAuth. Right now, CloudOS only authorizes apps to a pico. Once they are authorized, they have access to the entire API. This needs to be locked down. The point of the PIXEL project is to create an easy way for developers to indicate what rights they need, so users can accede and then for those rights to be granted. The PIXEL project is here.