...

• Explain what a pico subscription is
• Understand pico-to-pico relationships based on subscriptions
• Use the developer tools to manage pico subscriptions
• Programmatically link picos using a subscription and have them interact. 

Prerequisites 

You should have already completed the following lessons:

• Pico Engine Quickstart lesson. (Be able to register and install rulesets)

• Events and Queries Lesson. (Be able to create channels and understand how events are raised on channels)

• Pico State Lesson. (Be able to store and retrieve state using entity variables, both simple and complex)

• Pico-Based Systems Lesson. (Be able to manage the pico lifecycle using UI and programmatically)

• Read Wrangler Subscriptions description.

Contents

Subscriptions

Subscriptions play an important role in building systems of picos. In Pico-Based Systems Lesson, you created child picos. If the parent-child relationship were the only one that existed, we could create hierarchies of picos, but not peer-to-peer systems of picos. Subscriptions allow us to establish relationships between any two picos. 

A subscription represents a relationship between two picos. It has a name and two channels, one from each pico participating in the subscription to the other. Each side in the subscription can be given a role to further identify the purpose of the subscription. 

Image Removed

In this diagram, from the perspective of pico A, the top channel is the one on which it receives incoming events and queries, so A knows this channel as Rx, and the bottom channel is the one on which pico A transmits events and queries to pico B, so A knows this channel as Tx. Conversely, pico B knows the top channel as Tx and the bottom channel as Rx. Each pico has its own perspective on the subscription.

Subscriptions may also include a role for each pico. From the perspective of pico A, its role in the subscription is known as Rx_role while pico A knows the role of pico B as Tx_role. On the other hand, from pico B's perspective, the role of pico A is Tx_role and its own role is Rx_role. Putting yourself in a pico's place, you can think of Rx_role as my role and Tx_role as the other's role.

Managing Subscriptions Programmatically

Wrangler provides functions, actions, and rules for managing subscriptions from within your KRL code.

In this section, we'll use a simple example. Here the owner pico has three child picos, as shown by the familiar black parent-child edges. However, let's say the "Mischief Pico" needs to communicate with the other two picos.

Image Removed

The subscriptions which we will create to enable this pico to pico communication are shown as dashed magenta lines. (This diagram is available at localhost:8080/?subscr )

...

Motivation

In the previous lesson, you learned about creating pico parent-child relationships. However, in distributed systems, not everything is a parent-child relationship. In fact, there are many systems which are based off of peer-to-peer relationships. Each node in a peer-to-peer system needs some way to communicate with a different node independent of a parent child hierarchy. For example, a flower store may wish to create a relationship with a delivery driver, so that the store can broadcast a new delivery request, and the driver can bid on delivering that request. This is where subscriptions come in. Subscriptions are a relationship link from one pico to another completely independent of the parent-child hierarchy. This lesson will show you how to create these subscriptions (relationships) among picos so that they may communicate directly with each other rather than through some other median.

Prerequisites 

You should have already completed the following lessons:

• Pico Engine Quickstart lesson. (Be able to register and install rulesets)

• Events and Queries Lesson. (Be able to create channels and understand how events are raised on channels)

• Pico State Lesson. (Be able to store and retrieve state using entity variables, both simple and complex)

• Pico-Based Systems Lesson. (Be able to manage the pico lifecycle using UI and programmatically)

• Read Wrangler Subscriptions description.

Contents

Subscriptions

A subscription represents a relationship between two picos. It has a name and two channels, one from each pico participating in the subscription to the other. Each side in the subscription can be given a role to further identify the purpose of the subscription. 

Image Added

In this diagram, from the perspective of pico A, the top channel is the one on which it receives incoming events and queries, so A knows this channel as Rx, and the bottom channel is the one on which pico A transmits events and queries to pico B, so A knows this channel as Tx. Conversely, pico B knows the top channel as Tx and the bottom channel as Rx. Each pico has its own perspective on the subscription.

Subscriptions may also include a role for each pico. From the perspective of pico A, its role in the subscription is known as Rx_role while pico A knows the role of pico B as Tx_role. On the other hand, from pico B's perspective, the role of pico A is Tx_role and its own role is Rx_role. Putting yourself in a pico's place, you can think of Rx_role as my role and Tx_role as the other's role.

Managing Subscriptions Programmatically

Wrangler provides functions, actions, and rules for managing subscriptions from within your KRL code.

In this section, we'll use a simple example. Here the owner pico has three child picos, as shown by the familiar black parent-child edges. However, let's say the "Mischief Pico" needs to communicate with the other two picos.

Image Added

The subscriptions which we will create to enable this pico to pico communication are shown as dashed magenta lines. (This diagram is available at localhost:8080/?subscr )

Prepare for this section by manually creating three child picos of your root pico.

...

...