Event Channels

If you read the example on event subscription, you know that tokens play a large role in routing the events from one network to another. I don’t think of the token as identifying the network since there’s a separate identifier for that. Rather, the token represents a channel. Consequently, in the On Call TA demo, the TAs’ personal event networks subscribe to the events from the class network by supplying an event channel to the class network.

The token is more properly known as the event channel identifier (ECI), although I think we’ll often end up thinking of the token as representing the channel itself. An event channel, right now, has only a single name associated with it, but in the future you’ll be able to associate other information with the channel so that rules can contextually respond to events on a channel-by-channel basis.

To get a view of this, consider the following diagram.

Tim’s personal event network has a number of apps installed. It’s also is listening on many event channels. These channels are carrying events about everything from Tim’s phone and appliances to merchants he frequents.

REI and the flowershop both have separate channels into Tim’s personal event network. Consequently, Tim can

• Manage them independently. If REI starts spamming Tim with events he doesn’t like, he can simply delete the channel and they’re gone.
• Permission them independently. Tim might want to get certain events from REI and other’s from the flowershop. Which events can be carried on which channels is up to Tim.
• Respond to them independently. Tim might want to get notification events from the flowershop delivered to his phone today because it’s his wife’s birthday whereas normally merchant communications are sent to his mail box.

Tim is in charge of whether and how events are delivered. He manages the channel, delivery, and response while the publishers of these event choose the content.