...
Similarly, the Thing1 Pico participates in just one subscription. Doing the same sky/cloud query to its ECI will show something like this:
...
In fact, after the pending subscriptions were created, the Subscriptions rule for wrangler/subscription raises the wrangler event "inbound_pending_subscription_added" passing along all of the attributes. It is up to your pico to react by either accepting or rejecting. This cookbook example shows how to write a rule that auto-approves subscriptions. Generally, promiscuously approving pending subscriptions is a security risk, so most auto-approvals take place where something about the subscription requestor can be verified. For example, a child might be programmed to automatically approve subscription requests from its parent, after checking that the invitation came in on a channel that can be verified as being from the parent.
For now, to complete the manual process, we will send this sky/event to the Thing1 pico (line break added for readability–your URL will be all in one line):
| Code Block |
|---|
http://localhost:8080/sky/event/cj0deky3l0007khpqdmo4037y/approve/wrangler/pending_subscription_approval?subscription_name=mischief:thing1 |
Checking the Thing1 pico again, you will see that its one subscription now has the the status of "subscribed". At the same time, that subscription in the Mischief pico also now has the status of "subscribed".
Writing rules to manage subscriptions
Since most of the heavy lifting is done by the Subscriptions ruleset, it is easy to initiate, approve, and use subscriptions inside of your own rulesets.
Initiating subscriptions by introduction
It is possible to initiate a subscription with a rule running in a pico which has in its possession the ECI's of the two picos which need to be related by the subscription. For example, once we have set up the three child picos, Mischief, Thing1, and Thing2, we can install a ruleset into each of them. Simple examples are available in this repository.
The owner pico has all of the ECI's in its array of children (maintained by the io.picolabs.pico aka Wrangler ruleset), but it doesn't know which is which. So we added this rule to allow it to distinguish between the Mischief pico and the thing picos.
| Code Block |
|---|
rule mischief_who {
select when mischief who
pre {
mischief = event:attr("eci")
things = wrangler:children().map(function(v){v.eci})
.filter(function(v){v != mischief})
}
always {
ent:mischief := mischief;
ent:things := things
}
} |
The ruleset for the Mischief pico sets up a button "mischief/identity" in that pico's Testing tab which will send this event to the owner pico.
Once the owner pico has all of the ECI's, the code to introduce the Mischief pico to each of the thing picos is straight-forward.
| Code Block |
|---|
rule mischief_subscriptions {
select when mischief subscriptions
pre {
mischief = ent:mischief
thing1 = ent:things[0]
thing2 = ent:things[1]
}
if mischief && thing1 && thing2 then noop()
fired {
event:send(
{ "eci": mischief, "eid": "subscription",
"domain": "wrangler", "type": "subscription",
"attrs": { "name": "thing1",
"name_space": "mischief",
"my_role": "controller",
"subscriber_role": "thing",
"channel_type": "subscription",
"subscriber_eci": thing1 } } );
event:send(
{ "eci": mischief, "eid": "subscription",
"domain": "wrangler", "type": "subscription",
"attrs": { "name": "thing2",
"name_space": "mischief",
"my_role": "controller",
"subscriber_role": "thing",
"channel_type": "subscription",
"subscriber_eci": thing2 } } )
}
} |
The ruleset sets up a button in the owner pico's Testing tab, "mischief/subscriptions" to send the event that causes this rule to evaluate.
The final step is that a rule selecting on wrangler/inbound_pending_subscription_added in each of the thing picos will complete the subscription process.