In this section we describe the mapping of computational entities to processes in our engineering model and explain the distribution of these processes onto machines in a public display network.
5.3.1
Application Processes
As described in chapter 4, Applications are responsible for rendering content onto Displays. More- over we have argued in chapter 3 that the software infrastructure is required to provide support for proprietary content and applications that, for example, use native APIs to interface with sensor platforms and actuators (see requirement R11). These APIs may only be available for specific programming languages. We therefore cannot assume that all experimental Applications are im- plemented using the same programming language. As a result we propose to engineer Applications (which represent such experimental applications in our computational model) as separate processes that can be implemented using the researchers’ programming languages of choice.
Distribution of Application Processes
The decision where to host Application processes is limited by the main function of Applications to produce output on public displays. Solutions exits, such as the X display protocol [SG86] or the RFB protocol [Ric07], that allow processes that produce graphical output to be hosted on remote machines. In this model, the output produced by these processes is transferred over the network to the machines where it is to be displayed. However, these solutions only provide limited frame rates and are typically not suitable for videos or animated content with a suitable quality. Moreover, the graphics hardware of most of today’s computers feature accelerated graphics output based on in-silicon implementations of graphics APIs. For example, OpenGL [Ope08] hardware support often provides accelerated 3D output. However, these accelerations are not available if output is produced on a remote machine: hardware accelerated output is generated by the actual graphics hardware and can therefore not be accessed by software solutions, such as X or RFB. It is possible to redirect the graphics signal to a video capture card that converts the signal back onto a digital video stream that can be sent over the network. However, the bandwidth requirements of streaming uncompressed, high-resolution, high-frame-rate videos over the network limit the scalability of this solution as the number of public displays and Application processes increases. Compressing the videos before they are streamed places high requirements on the CPU of the compressing system and typically leads to delays between the capturing of input and the manifestation of the corresponding stream output. As a result, we propose to execute Application processes on the actual display machines.
Separation of Functionality
The functionality of an Application process can be further decomposed into two parts:
• a rendering engine that is specific to the content type supported by the Application. For
example, there may be rendering engines that are able to display video files, and other rendering engines suitable for showing web content.
• aprotocol engine that implements the state machine that underpins the Application process
and that exposes theChangeState operation to Displays and Schedulers. The protocol en- gine is also responsible for realising the intended transactional semantics, including resource locking, and the handling of commitandabortprotocol messages (see section 5.4.2).
While support for different content types calls for the development of different rendering en- gines for each of these content types, the protocol engine is generic across all Applications and can therefore be re-used for the construction of different types of Applications. In our engineering of Applications we propose to follow this separation: each Application process is composed of a genericprotocol wrapper that is common for the engineering of all Application processes that are implemented using the same programming language, and a content-type-specific renderer. Appli- cation processes are formed by combining one renderer with the appropriate protocol wrapper. Renderers expose an interface that is common to all renderers, which enables arbitrary renderers to be combined with the generic Application protocol wrapper without requiring any modifications to that wrapper. This interface consists of the following set of methods:
• a constructor, accepting the url of the content as argument.
• prepare, causing the renderer to pre-fetch the content.
• make_visible to make the renderer’s output visible on the display, and to instruct the renderer to start playback if continuous media is used.
• make_not_visibleto make the renderer’s output not visible and to instruct the renderer to pause playback.
To implement transactional semantics (see design proposition DP6), all methods accept a ‘commit’ flag as a parameter. This flag indicates whether the call is part of a prepare phase (i.e. whether the mere possibility of executing the action should be checked) or whether the action should be committed (i.e. the action should actually be carried out). As a result aChangeState
operation that is carried out in a transactional context typically triggers two invocations of the corresponding renderer method: a first time with cleared commit flag during prepare phase, and a second time when the transaction is committed, this time with the commit flag set. The act of aborting a transaction does not modify the playback state or visibility state of renderers. To simplify the engineering of renderers, our current engineering model does therefore not provide any means for notifying renderers if transactions are aborted. However, we do acknowledge that as a result renderers may reserve and hold on to resources (for example as part of state transitions into Application statePREPARED) and we would therefore expect future versions of the engineering model to provide means for notifying renderers if transactions are aborted.
All operations except for the constructor return a result code indicating whether the invocation was successful.
5.3.2
Display Processes
Each machine in an installation typically offers one or more conceptual Displays (as discussed in chapter 4). Since Displays are responsible for instantiating Application processes, at least those functional parts of Displays that are in charge of creating Application processes have to be hosted on those physical machines that Applications are to be instantiated on.
The other functions that are performed by Displays (i.e. the oversight of the visibility of Ap- plications, the communication with Handlers, and the detection of conflicts between Applications on the same Display) can in principle be provided by processes that are executed, for example, on a remote server. However, the distribution of the functionality provided by Displays into sepa- rate processes would result in additional overheads incurred by the communication between these processes. We therefore propose to represent each Display entity in the computational model as a single Display process in the engineering model. Each Display process implements all of the functions of a Display entity. Moreover, Display processes are hosted on the particular display machines that are managed by them.
5.3.3
Handler Processes
The engineering of Handlers as separate processes is partly dictated by the potential need for Handlers to interface to specific hardware components, such as audio/video matrix switches (see requirement R15), whose APIs may only be available for certain programming languages. It is therefore unlikely that all Handlers could be implemented in a way that enables them to be integrated directly into Display processes, e.g. in the form of modules. Moreover, according to our computational model, single Handler instances may be associated with multiple Displays. This means that if Handlers were integrated into Display processes, then Handler instances would have to implement two different mechanisms for communicating with Display processes: a native interface for communication with the Display process they themselves are part of, and a remote interface for communicating with other Display processes in the system that the Handlers are associated with. This remote interface may, for example, be based on direct communication between remote Display processes and the Handler. Alternatively, Handler stubs may be associated with each remote Display, and a remote Display may in this case communicate with a Handler by invoking operations on its own Handler stub, which as a result interacts with the (remote) Handler.
To simplify the construction of Handlers we therefore propose to engineer Handlers as separate processes that communicate with Displays using a protocol that is layered on top of the event channel. In our engineering model, each individual Handler process is addressable using a globally unique Handler Identifier. The association between Handler processes and Display processes is read and parsed by Display processes on start-up. Changes to this configuration therefore require Display processes to be restarted.
By allowing Display processes and Handler processes to communicate using the event channel, Handler processes can in principle be hosted on any computer in the display network, as long as a connection to the event channel can be established. However, the need to interface with specific hardware that cannot be accessed using remote invocations may limit the ability to freely distribute specific Handlers. For example, some LCD displays can be switched on and off using commands that are issued over an RS-232 connection. A Handler can be constructed that is responsible for switching such a display on or off based on whether content is currently visible on the display or not. It makes sense to host such a Handler on the machine that the display’s RS-232 interface is
connected to.
5.3.4
Scheduler Processes
Design proposition DP2 proposes to allow Schedulers to be distributed arbitrarily in the display network. As a result we propose to engineer Schedulers as separate processes. The API that Schedulers use to influence the life-cycle and visibility of Applications uses the event channel to communicate with Display processes and Application processes. As in the case of Handler pro- cesses, Scheduler processes can therefore in principle be hosted on any machine in the display network. This means that researchers can, for example, execute their experiment-specific Sched- ulers on their own computers, as long as connectivity to the event channel can be established from these machines. However, the need, for example, to interface specific hardware, such as sensors, that can only be accessed from certain machines may require certain Schedulers to be executed on specific computers.