Lately, I've been talking a lot about personal clouds and personal event networks. The power of a personal event network is harmonizing your various lives: business, personal, and social. Having a personal valet that thinks about you---your needs, your quirks, your life. A personal event network puts you into a position of just making go--no go decisions, rather than having to get involved in all the gritty details of how they get done. A real personal assistant is only for the realms of Kings, Presidents & CEOs. A personal event network provides that same luxury to the rest of us. Personal event networks will enable new kinds of commerce that are not only more efficient, but also more gratifying.

The release of the Sky API brings the vision of personal event networks closer to reality on the Kynetx platform. Our previous event API, Blue, required that the ruleset IDs be specified, Sky does not. Rather Sky uses saliance data--information saying which rulesets are listening to which events--to determine the rulesets that see any given event. Of course, this is done on an entity-by-entity basis, making it personal. You will have activated a different collection of rulesets than I and therefore an event raised on your behalf will fire different rules than an event raised for me--automatically. Sky is compatible with the Evented API specification.

For now, most KRL programmers won't notice any difference since the Blue API is still supported and most endpoints are still using it. However, as endpoints--particularly KBX--begin using Sky, all kinds of new behaviors will open up. I'll have an example up on this blog in a few days.

There are several changes to default behavior that will take place immediately, regardless of endpoint, and could affect your KRL rulesets if you're made heavy use of explicit events.

The first change affects what rulesets see an explicit event. Previously, if you didn't specify a ruleset in the raise statement in the rule postlude, the explicit event was only seen by the current ruleset. With this release, an explicit event that does not specify the ruleset will be seen by any ruleset that the user has activated if saliance data indicates that it listens for that event.

For most developers and apps, this won't be a problem because even if you use explicit events, you've likely used different event names in different rulesets. However, if you experience problems, there is a work around. You've always been able to specify the rulesets for which an explicit event is being raised. You can specify the current ruleset using the Meta library to retrieve it's ruleset ID like so:

always {
  raise explicit event foo for meta:rid()
}

The second change involves the default version for rulesets specified in a raise statement. Previously, if you didn't specify the version, KRE used the version of the ruleset where the raise statement was executed to determine the version of the ruleset that saw the explicit event. This was handy when developing an app that comprised multiple rulesets since you didn't have to keep pushing things to production or change the version in a lot of files when you were done.

We believe that the correct default behavior is to default to production if no version is specified since this makes sharing rulesets between users easier. The work around for this if you want the old behavior is to specify that the target ruleset should use the source ruleset's version by constructing the target ruleset identifier like so:

raise explicit event foo for "a16x56.#{meta:version()}"

Of course, you don't need to use the Meta library, you could set the version in a configuration module and then just use that value in constructing the target RID.

I'm very excited about Sky because it opens up new possibilities for creating personal event systems. Watch for a blog post in a few days that shows why this is so.