At the core of the abstractions we provide is the concept of a Display. A Display represents a specific combination of audio & video sources and audio & video sinks in a given installation and hides the potential underlying complexity of non-standard hardware mappings from developers, allowing us to provide “support for non-standard and dynamic hardware setups” (requirement R15). Displays act as outlets for the output emitted byApplications, stateful entities that render the visible or audible output for content items or experimental applications. Each instance of an Application is instantiated on a single Display. Displays expose operations that allow Applications to be instantiated and terminated. They also offer operations to control the visibility of output produced by Applications. Moreover, each Display is responsible for detecting and handling con- tention between Applications that are instantiated on the same Display, allowing us to support
Conceptual Display Display H H H Handlers A A A Scheduler A A A Display H H H Handlers Conceptual Display Applications Scheduler Scheduler Applications
Figure 4.2: Overview of the computational model.
“arbitration between conflicting pieces of content” (requirement R3). Contention is handled based on a priority value that is associated with each Application. Policies can be employed, for exam- ple, to allow higher-priority Applications to preempt Displays from lower-priority Applications, addressing the requirement R7 (“support for priorities and preemption”).
Conflicts between different Displays that occur when two or more Displays share a piece of underlying hardware that cannot be accessed concurrently are addressed by Handlers. Handlers are optional policy components that can be associated with Displays to extend the functional- ity provided by our software infrastructure. Besides detecting conflicts between Applications on different Displays, Handlers can be used, for example, to toggle the inputs on LCD displays to ensure that the correct inputs are selected as output from Applications is displayed, or to create audit trails of Display activity (requirement R14: “support for audit trails”). To achieve their aims, Handlers intercept the invocations of operations on Displays. The use of Handlers allows us to “provide support for non-standard and dynamic hardware setups” (requirement R15) without having to expose the details of these setups to users of the model.
Entities that control the life-cycle of content and its visibility on Displays are calledSchedulers. Multiple schedulers may be active in the display network at the same time, and these schedulers may simultaneously operate on the same set of displays, allowing us to provide “support for a wide range of scheduling criteria” (requirement R4). Schedulers are able to control Applications using a distributed API that provides remote access to the operations exposed by Displays and
Applications. As we have outlined above, providing remote access allows Schedulers to be executed on any machine that is connected to the display network. Researchers may use this feature to enable Schedulers to interface with native APIs to sensors and interaction devices that are only available on certain computers (requirements R8 and R9). The API provides operations for instantiating and terminating Applications, and for directly controlling the visibility of their output on Displays. This level of control enables researchers to precisely control the appearance of applications on public displays and enables them to arrange content into precisely orchestrated sequences (requirement R12: “support for orchestrated performances”). API operations can be grouped into transactional blocks that are executed as atomic units. Transactions also provide isolation, i.e. intermittent states of transactional blocks are not made visible to other entities in the system. Moreover, they ensure that intermittent states of transactional blocks remain invisible to humans observing the displays. We call this propertyvisual isolation. The consistency property of our transactions ensures that the results of transactions comply with the policies of our software infrastructure, e.g. preventing a Display from having two Applications visible at the same time as result of a transaction. By providing these transactional semantics we are able to address the requirement to provide “support for atomicity and isolation” (requirement R13). Finally, the API allows Applications to be aggregated into Application Groups. API operations can be carried out on individual Applications as well as on Application Groups. By enabling developers to invoke operations on Application Groups we provide “support for bulk operations” (requirement R6).
Sources of context information and interaction devices are both modelled as separate computa- tional entities. Information provided byContext SourcesandInteraction Devicesmay be accessed by Applications and Schedulers either using native APIs or using a common eventing framework that can be used as foundation for developing “support for context-sensitivity and personalisation” (requirement R8) and “support for interactivity” (requirement R9).
An overview of the relationships between the entities of the computational model is depicted in figure 4.3.
Display Application Application Application control life-cylce and visibility of render output onto Handler Handler Handler enforce policies on arbitrate between,
instantiate and terminate Handler HandlerContext Source Handler Handler Interaction Device provide interaction events provide interaction events provide context information provide context information Scheduler SchedulerScheduler API Display Display
Figure 4.3: Relationships between entities in the computational model.