In Triveni, the event delivery model is fair multicast: events are eventually and simultaneously delivered to all interested listeners. From an object point of view, one can view communication in Triveni as a refinement of the Observer pattern. Recall that in the Observer pattern, events are generated by event sources (subjects), and one or more listeners (observers) can register with a source to be notified about events of a particular kind. Triveni thus uses the registration and multicast mechanisms of the Observer pattern, but does not employ callbacks from the listeners back to the sources.
Triveni handles the registration of the Observer pattern by scoping mechanisms. In other words, every Triveni event has by default an associated scope established via the traditional programming language mechanisms such as local variables. A Triveni Expr then, by default, can listen to all events whose scopes include it.
Consider the code presented in example 4 above; this establishes k connections, one each between the PlayerWindow and each of the k ships.
This ``wiring'' for event delivery is deduced from the program structure. The top level parallel composition sets up a group of Triveni processes that communicate via broadcast. The local construct renders the outside world oblivious to the occurrence of the events of ShipUIEvent label (or variants thereof). Furthermore, in the concrete design later, ships are sensitive to only ShipUIEvents. Consequently, after renaming, the different ships occupy disjoint bands of the communication bandwidth leaving the PlayerWindow as the sole observer of each individual ship, and leaving each ship registered as an observer of only PlayerWindow.