Description
Visibility is an attribute that applies to event propagator objects and is used as a means of removing extraneous nodes from consumed event trees. Visible objects are referred to as 'opaque', and invisible objects are referred to as 'transparent'.
Events that emanate from objects that are designated 'transparent' are not propagated as part of their containing event trees. With the notable exception of collector events, the information held in most propagator events is seldom useful to consuming active objects. As a result, access functions are not generated for transparent objects.
There are a number of reasons for designating objects as transparent. Firstly, it will save the carrier bandwidth used to move event trees between machines, and secondly, it will reduce the CPU required to unpack event trees. Perhaps more importantly, it can be used as a means of simplifying circuit prototypes.
Example
The 'switch' circuit definition below will distribute a subset of its consumed events to each connected client. The use of transparent objects ensures that the provided event tree has identical structure to its consumed event tree which simplifies the interface definition and increases the filter's re-usability as an off-the-shelf component.
In order to parallelize the most general classes of problems, it is necessary to have equivalents for 'if-then-else' and/or 'switch' statements that allow control to branch on data values. When data objects become very large, or are distributed to many consumers, it is not practical to copy data. In the most general case where events are shared across distributed memory systems (e.g. networks) it is not possible to pass raw references. The example circuit solves these problems, and allows the consumer to see the data by reference in shared memory, but transparently moves the data in the distributed case. It will deliver data optimally in all cases.
The input event tree (specified by the In subscription) can take any form, and the 'switch' method is passed references to its data. Having inspected the data (problem specific logic), it will signal one of the 'N' semaphore elements, which corresponds to selecting a label in a switch statement equivalent. This allows the appropriate collector element to progress, and collect the 'input' event from the competer. This compound event is then split to isolate the input event, and the result (the original event) is then passed to the appropriate distributor element for distribution to whichever consumers have connected to that element. Since all the intermediate objects are 'transparent', and the collector is implicitly transparent (it has been 'split'), consumers see the original event tree.
This sub-circuit (and many others like it) can be re-used in any application requiring 'switch' type branching logic. Each specific case can have a different event tree, different control method, and a different value for 'N'.