Page Comparison

Warning

title	Draft Specification

This specification is currently a draft under development.

Issues:

We need a picture. Fixed
Unclear where or who raises approval and rejection events. Should be clear now?
Some examples show postlude event raise where PJW thinks an event:send() is correct
Not sure why cloudos:CloudOS_subscriptionRemoved and cloudos:CloudOS_subscriptionAdded have CloudOS_ prepended when the event domain gives that information. Also, the provided examples don't have the prepend. Fixed, removed the CloudOS_ prefix.
An example of subscriptionList() would be nice

The CloudOS Subscription Event Protocol provides an event based model for managing subscriptions between Personal Clouds. The current implementation of the protocol will create a symmetric relationship between both Personal Clouds. Cloud subscriptions are done in such a way that both the originating and target clouds end up with a unique event channel to the other that is specific to the purpose for the subscription.

...

Any ruleset wishing to create the subscription signals the CloudOS to do so by raising the system:subscribe event. This is most often done in a rule postlude as shown in the following example:

Code Block

theme	Confluence
language	javascript

fired {
  raise cloudos event subscribe
    with channelName   = "Coworkers Bob+Ted"
    and  namespace     = "MyFriends"
    and  relationship  = "friend-friend"
    and  targetChannel = "3f15b820-fa7f-012f-4c6e-00163ebccdcd"
    and  _api = "sky";
}

The CloudOS service raises the cloudos:subscriptionRequestAdded to the originating cloud:

Domain	`cloudos`
Type	subscriptionRequestAdded
Attributes	targetChannel, backChannel, namespace, relationship, channelName

The backChannel attribute contains an ECI for the originating cloud that the CloudOS service has created and will pass to the target cloud.

...

Versions Compared

Old Version 31

New Version 32

Key