Last week I published a roadmap for the Personal Cloud Operating System (PCOS). This post outlines what kinds of things needed to be built in order to make a PCOS viable and usable. One major category in the roadmap was labeled "User-Space Applications and Utilities."

I want to introduce and define a major category of user-space applications in the PCOS and call them "services." Services have a specific architecture and usage pattern than sets them apart from other KRL programs. I introduced the service pattern last January in a post on using Foursquare with KRL but didn't give it a name.

I've referred to this pattern at various times in the past as a "manager" or even a "module" but neither of those terms capture the importance of this pattern, so I've decided that "service" is the right term. Referring to it as a module leads to confusion since modules don't normally need to be installed in the PC when they're used, but a service does. The fact that a service is also a module is an implementation detail.

The component labeled the "personal data manager" (PDM) in Foursquare post is a perfect, small example of a PCOS service. The PDM service uses a combination of rules, functions, and entity variables to create an effective service for storing simple elements of personal data. Beyond simple storage, however, the service acts as a full-fledged actor in personal cloud because it listens for and emits relevant events.

PCOS Service Principles

To understand the pattern more fully, let me lay out a few principles and then we'll review the code in the PDM service in some detail.

A PCOS service responds to and emits a defined set of events. These events can be thought of as a service protocol or API. Defining a service requires that both kinds of events and their respective attributes be specified. This allows other services and applications in the PCOS to take advantage of the service.

Services should avoid being leaves in the event hierarchy. This means that they should emit events to indicate any state changes that other services and applications might wish to be made aware of.

A PCOS service may also define a set of functions for interrogating the service. Services cannot modify their visible state in response to such an interrogation. Interrogation functions are made available to other applications and services via a module interface.

PCOS services usually maintain entity-specific state. In the case of the PDM service, the entity-specific state consists of personal data. The data stored by the service is dependent on the particular purpose of the service and is only made available through functional and event-based interactions as defined in the two preceding paragraphs. Services implemented with KRL persistent variables get entity-specific state without any effort by the programmer. If a service uses an external data store, the developer must take care to ensure that the service provides entity-specific state.

The key to understanding how a PCOS service is implemented in KRL is to realize that KRL rulesets create entity-specific closures over the persistent data declared within. Thus the rules and functions declared in the ruleset implementing the service automatically have access to a bundle of state for whichever user the service is running for.

PDM as a PCOS Service

Let's review the design of the PDM service to see how this works. The PDM service has a rule, add_location_item, that is used to add a new location waypoint for the user. The add_location_item rule listens for the pds:new_location_available event.

rule add_location_item {
  select when pds new_location_available
  always {
    set ent:location{event:attr("key")} 
        event:attr("value");
    log "Saw " + event:attr("key") + " data";
    raise pds event new_location_item_added 
      with key = event:attr("key");
  }
}

Whenever such an event is raised, the rule does three things:

1. Stores the location variable in an entity variable.
2. Writes a log message
3. Raises a new event, pds:new_location_item_added

Most services will raise events as well as respond to them as shown here because that ensures they are actors in the PCOS. Other services or applications can respond to changes in the service state by listening for those events. For example, in this case, a reminder service might be listening for the pds:new_location_item_added event so that it can remind the user when they enter or leave a particular geofence. Notice that the reminder service isn't responsible for processing the location data, just listening for a particular event.

Later, this item can be used by other applications through the get_location() function:

meta {
  name "Personal Data Manager"
  provides get_location
}

global { 
  get_location = function (k) {
    ent:location{k};
  };
}

A function, made available through the module interface (notice the provides pragma in the meta section) provides a convenient way for other applications and services to interrogate the data in the PDM.

Future Work

While the basic pattern for services is clear, there is still much to be done.

• First, there are plenty of services to specify. Some of these, like personal data, present difficult schema decisions.
• Services might provide interfaces to other online APIs. This implies that users should be able to chose the underlying API in some cases. For example in the case of the PDM service, one user might opt for native storage (in the PC), other's might opt for Personal.com gems, and a third might opt for a Sing.ly locker. Ideally, the service interface should remain constant so other services and applications can take advantage of it regardless of the API it is fronting.
• We need a permissioning model. In the PDM service I use as an example, there's no authorization required to use the data. Any application or service installed in the PCOS can see the location data or raise an event saying new location data is available.

We're working on all of these at present. Some things, like the permissioning problem will require kernel-level changes in the PCOS. Others, however, such as the definition of services is something almost anyone could participate in. I look forward to hearing your suggestions and potential services and having discussions about their design.