Summary
Kynetx has build what amounts to a functioning kernel for a cloud OS. But there's more to an OS than the kernel. This post outlines what else is needed to create a fully usable cloud OS.
In my recent white paper, From Personal Computers to Personal Clouds: The Advent of the Cloud OS, I make the case that Kynetx is building an operating system for personal clouds. Operating systems provide a core set of services around identity, data and communications, as well as a programming model.
One of the distinctions in an operating system is "kernel space" vs. "user space". Kernel space is that portion of the memory reserved for running the kernel, its extensions, and device drivers. User space is less privileged. As the name implies, anyone can write programs and run them in user space.
What most people think of when they think of an operating system like Windows or Linux is the user interface to the OS: the windowing system. While the windowing system is tightly coupled to the kernel in Windows, Linux let's users choose one. Which points out something important: the windowing system, command line, and tools that we think of has being the OS, are in fact just programs running in user space.
Recently the Kynetx Cloud OS reached an important milestone: we started building out important pieces of the OS' functionality in what you can think of as user space. Specifically, rather than building subscription into the underlying platform—what you might think of as the kernel—we are implementing cloud subscription as a KRL application.
The following represents a roadmap of what needs to be done to get from having a functioning kernel to a real cloud operating system that includes the necessary user-space tools and utilities. Note that the roadmap does not necessarily indicate priority or order.
Kernel-Space Enhancements
The "kernel" of the Cloud OS is the Kinetic Rule Engine (KRE). It implements and uses multiple APIs. The primary function of KRE is to provide core personal cloud services. The following are some of the big improvements I have planned for KRE:
- Document and improve API for accounts
- An account is a KEN (Kynetx Entity Number) and associated RIDs (Ruleset IDs) and CIDs (Channel IDs).
- Current account system is built on a Rail/MySQL platform. New system should be supported by an API in KRE and built as a user-space application.
- Improve and simplify installation process for KRE
- Allow Github and other online code repositories to be used as rule repositories. This involves generalizing the ruleset identification process so that the RID maps to a repo, rather than assuming that the ruleset is always in the Kynetx repo.
- Provide better thought out logging information for debugging. Current logging information includes information that developers don't need and probably doesn't include information they could use.
- Create an event log API for each PEN (personal event network) so that interested users can review the events that their PEN has seen. Think of this as the system log for the Cloud OS.
- Performance improvements
- XDI integration
- Implement the queue architecture for KRE (see diagram).
This would allow:
- Priority scheduling of rulesets
- support for other languages besides KRL
- better, more modular operational management
User-Space Applications and Utilities
There is important functionality that needs to be built at the user-level to support PEN interaction. The following are some of the user-space utilities that should be built. Many of these exist in some form or another right now, but should be rebuilt as user-space applications. Some of these will require modification to KRE.
- Inter-PEN subscription support
- Application configuration support module
- PEN management (currently handled by Rails/MySQL Web app)
- Authentication
- Authorization
- Ruleset installation
- Channel creation
- Dashboard for PEN interaction
Base Personal Cloud OS Applications
Just as any OS you buy for your personal computer has a set of applications that you expect to find like address books and browsers, a Cloud OS needs a set of user applications. The following represent the ones I think are critical to any personal cloud:
- Calendar - support for calendar events is critical in an evented system. There are two aspects:
- User-level calendars (i.e. ties to Google calendar, etc.)
- PEN-level calendars (i.e. Show me when the kitchen has been occupied) There could be thousands of these, so management, viewing, etc. is a challenge.
- Contacts - This goes beyond the contacts that we have now to the interrelation between PENs.
- TODO - support for things to be done. This is likely used more by apps to keep track of TODOs than by the user, although user notification would be critical
- Notifications - user configures one thing to contact her and then let apps in her personal cloud mediate interactions with other people and things.
Conclusion
Beyond the ideas I've outlined above, there are other services that could be layered on top of the personal cloud. Certainly there are plenty of applications to be built—many of which I can't even imagine. There are also services like discovery, reputation, etc. that will enable rich, authentic, and multi-faceted relationships to be supported between personal clouds.