Note: this page is inspired by (and often copied verbatim from) the original fourth lesson, Lesson: Pico to Pico Subscriptions.
Learning Objectives
After completing this lesson, you will be able to do the following:
- Understand pico-to-pico relationships and subscriptions
- Use the developer tools to manage pico subscriptions
- Link two or more picos with a subscription programmatically and have them interact.
Prerequisites
You should have already completed the following lessons:
Pico Engine Quickstart lesson. (Be able to register and install rulesets)
Lesson 1. Events and Queries. (Be able to create channels and understand how events are raised on channels)
- Lesson 2. Pico State. (Be able to store and retrieve state using entity variables, both simple and complex)
Lesson 3. Pico-Based Systems. (Be able to manage the pico lifecycle using UI and programmatically)
- Read Wrangler Subscriptions description.
Subscriptions
Subscriptions play an important role in building systems of picos. In Lesson 3. Pico-Based Systems, 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.
Subscriptions Using the UI
To be written...
Managing Subscriptions Programmatically
Wrangler provides functions, actions, and rules for managing subscriptions from within your KRL code.
The following sequence diagram illustrates a point at which a subscription will be needed. You will recall from the previous lesson that the section collection pico may handle the event section needed. Once the section pico is ready, the section collection pico could assign it a new channel and send the ECI to it's parent, the registration pico. Similarly (code left as an exercise) the student collection pico could inform it's parent (also the registration pico) of a private ECI for the appropriate student pico. Having both ECI's, the registration pico could introduce the two picos to each other, so that they now share a subscription. This introduction, and the creation of the subscription, are represented by blue arrows.
"Stu" represents the pico for the student "Alice" and "Sec" represents the pico for section "A". Remember that there might be thousands of students and thousands of sections, of which this diagram shows only one of each.
We saw in the previous lesson, that when the section collection pico handles the event section needed, it may be able to provide it immediately, because it already exists, or we may need to create and initialize a new pico before it becomes available. This is illustrated by the note "possible creation of pico Sec". Also, we saw that the section pico might write its roster to the database and then ask to be deleted (by sending the event section offline to the section collection pico. This is illustrated by the note "possible end of pico(s)". Similar remarks hold for student picos.