Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

After completing this lesson, you will be able to do the following:

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

Prerequisites 

...

The following sequence diagram illustrates a point at which a subscription will be needed. You will recall from the previous lesson Pico-Based Systems lesson that the section collection Section Collection pico may handle the event section:needed. Once the a section pico is ready, the section collection Section Collection pico could assign it a new channel and send the ECI to it's parent, the registration Registration pico. Similarly (code left as an exercise) the student collection Student Collection pico could inform it's parent (also the registration Registration pico) of a private ECI for the appropriate student pico. Having both ECI's, the registration 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.

...

We saw in the previous lesson, that when the section collection 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 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 Section Collection pico. This is illustrated by the note "possible end of pico(s)". Similar remarks hold for student picos.

...

There is one step remaining in the subscription process. Just because a one pico offers a subscription to your another pico doesn't mean that your target pico is forced to accept it. This is manifest by the "status" of the subscriptions. For the originating pico, the status is "outbound" (short for outbound, pending), and for the other pico, the status is "inbound" (i.e. inbound, pending).

...

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):

...

The owner pico already 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 (which identifies itself by ECI) and the thing picosThing1 and Thing2 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
    }
  }

...