The adopted methodology is based on a derivative of the linguistic analysis model of human-computer interaction [6]. The derivative model introduces the notion of ``medium'' (in addition to ``device''), accounts for multi-tasking, and is stated in terms intended to provide better guidance for the developer. As discussed in a companion report in this issue [19], there are four levels of I/O:

The manner in which these components are interconnected by the various types of I/O is depicted in Figure 1. This figure differs from the corresponding one in [19] in the decomposition of the application into a frontend and a backend. There are two principal ways to view this split:

The basic flow of control is as follows: When the system is initialized, the workstation manager creates a default dialogue manager. At a later time, the user may interact with the workstation manager to create other dialogue managers or to create new windows for existing applications. Typically, however, one dialogue manager will suffice; it interacts with the user (via the workstation agent) to determine what applications (or methods) should be invoked, to specify the arguments to those commands (or methods), and to invoke frontend and backend services as necessary. Naturally, any number of applications may be running at any time; the user controls the input focus via the workstation manager.

This flow of control is typical of what has sometimes been referred to as external control, where the user guides the interaction [26]. Unfortunately, the vast bulk of existing applications exert internal control; they drive the interaction. Such applications are accommodated in two ways. First, all requests for arguments can be directed to the dialogue manager rather than to a specific workstation agent (or device driver). The dialogue manager can then determine the best interaction technique to use to specify each argument — just as it determines the interaction technique(s) for specifying a complete command. Second, a pre-existing ``shell' or ``executive'' may be invoked as an application, from which the ``real'' applications may then be invoked.

From the discussion thus far the reader may have inferred another difference between the model assumed here and that presented in [19]: support for a hierarchy of dialogue managers, rooted at the workstation manager. The manner in which the user interacts with the workstation manager — the meta-dialogue with the system — may be fundamentally different than the manner in which the user interacts with a typical application. Therefore, while the workstation manager remains a client of the workstation agent, it is regarded more as a (special) dialogue manager than as an application. Similarly, pre-existing shells invoked by a dialogue manager can themselves be regarded as dialogue managers, however antiquated. In the remainder of this paper, we will continue to use different terms for these three basic types of dialogue manager, but the reader should remain aware of their underlying similarities.

Another implication of the previous discussion is the availability of facilities for run-time ``instantiation'' of code, as when the workstation manager creates dialogue managers. Although this can be achieved in a shared-memory environment via dynamic linking facilities, the more general approach is to use multiple processes. Aside from support for run-time instantiation and dynamic binding, there are many other motivations for the use of concurrent programming techniques in the construction of interactive software. The reader is referred to the companion report in this issue [19] for a general discussion of motivations and techniques. It suffices to say here that we have adopted the ``team of processes'' approach discussed in that report.

In particular, our implementation methodology relies on the availability of lightweight processes and fast interprocess communication — through message-passing, shared memory, or both. Each of the four major software components discussed above — applications, dialogue manager(s), workstation manager, and workstation agent — consists of one or more processes sharing a single address space. Processes sharing the same address space may synchronize their access to shared data with spin locks or messages. Processes in different address spaces communicate solely via messages.

First, for purposes of this discussion, a device that implements both input and output is treated as consisting of two separate devices.

In order to be responsive to all input devices, each is associated with an independent process that accepts input only from its associated device. However, a great deal of experience has been accumulated suggesting that it is easier to write applications that accept a single stream of input events rather than multiple streams, one for each device. In our model, of course, most applications are not (or need not be) aware of individual devices or even media, but the dialogue manager must be. Therefore, it is desirable that the workstation agent optionally serialize the input from multiple devices that is logically part of the same input stream (dialogue). This suggests the addition of an additional process, the input demultiplexor.

On the output side the situation is somewhat different; the system is driving the device. This means that it is not necessary to have a separate process waiting at all times to serve that device. On the other hand, it is desirable to have separate processes for each communications medium — an audio manager, a video manager, and a display manager, say. The display manager, in particular, would provide all the ``standard'' graphical output facilities of the system — the output facilities of GKS or PHIGS, for example. In fact, it should be capable of providing multiple sets of facilities at the same time.

The workstation agent also must provide the basic support for multitasking. Specifically, the input demultiplexor must be cognizant of multiple input streams and each output handler must be cognizant of multiple output streams. In the case of the display manager, for example, it should support multiple display files. Input and output streams should be kept separate, thus allowing an application to have one input stream but multiple output streams. The one exception to this rule concerns feedback.

Recent experience has shown that the feedback facilities of standard graphics packages conflict with contemporary interest in object-oriented programming and direct manipulation [5]. Specifically, very little of what is referred to as ``feedback'' relies solely on lexical information, and therefore cannot be implemented at the workstation agent level. Nevertheless, to the extent that lexical feedback is desirable, it must be possible to indicate to the input handlers when and how they should communicate with their corresponding output handlers.

The resulting structure looks like that in Figure 2, which depicts the workstation agent (TheWA [17]) currently implemented for the V-System.

picture(size 4.75in, postscript "figures/wa-structure.vps-fig")])

Figure 2. The Workstation Agent.

Analogous to the use of multiple input and output handlers, the dialogue manager employs multiple dialogue handlers, one for each ongoing dialogue. A ``master'' dialogue manager may be employed to synchronize access to the various shared databases, or traditional shared memory techniques could be employed. (Remember that all dialogue manager processes share the same address space in this architecture.) However, each dialogue helper is single-threaded, simplifying its implementation.

The information being shared includes:

The common algorithms being shared are those that make decisions, based on the various constraints, as to how best to interact with the user or the application at any given time. For example, when operating under external control, each dialogue helper is ``driven'' by a dialogue specification. For every abstract object, the appropriate decisions must be made as to which input events are acceptable or which output events should be generated. Typically, this entails translation from abstract (media-independent) to media-dependent representations, bearing user preferences and the like in mind. Sometimes, the dialogue specification will mandate the use of a specific medium or even a specific device.

When running an application that is exerting internal control, the dialogue helper merely accepts requests from the application rather than being driven by a dialogue specification. If the application requests input or output in a media-independent fashion, it is still possible for the dialogue helper to decide which specific interaction techniques to employ.

Finally, to the extent possible, the dialogue handlers provide syntactic feedback. Especially when under external control, the handler will do a fair amount of input processing, generating feedback directly to the various output handlers.

As noted above, the workstation manager is a ``special'' dialogue manager, one that manages the meta-dialogue consisting of all ongoing dialogues. A single process implementation will suffice in this case. Since it too interacts with the user, it must have access to some of the databases discussed in the previous section. At first glance, then, it seems reasonable to place the workstation manager on the same team as the other dialogue managers; indeed, the workstation manager could then be the ``master'' dialogue manager alluded to above.

However, if the workstation manager is in the same address space as the ``normal'' dialogue manager, neither can be as easily replaced independent of the other. Moreover, as previously discussed, the meta-dialogue for which the workstation manager is responsible may be qualitatively different than the typical user-application dialogue and, therefore, the databases may not be the same after all. Therefore, we suspect that the preferred approach is to place the workstation manager in a separate address space, replicating whatever information is common between it and the normal dialogue manager team.

Integration of conferencing facilities into the V-System required the addition of three new (types of) processes and a minor modification to TheWA. The three process types added were:

As shown in Figure 3, a fully replicated architecture was adopted, wherein the application is replicated at every participating workstation. Consequently, instances of the conference frontend and conference agent are also replicated at every workstation. There is, however, only one instance of the conference manager. A detail of the team and process structure on Host Y in shown in Figure 4, where boxes demarcate teams.

The conference manager receives commands from the conference frontend, validates them, and if valid, broadcasts them to all conference agents.3 The conference agents actually execute the commands with respect to their individual workstation environments. In this implementation, the conference agent, rather than the conference frontend, is responsible for invocation of shared applications — applications that are to be run in the context of the conference. Of course, before invoking an application, it must first determine which application to invoke, and with what arguments; it must act as a dialogue manager. However, rather than reimplementing dialogue management functions within the conference agent, it was decided that the only application a conference agent could invoke would be an executive. Any other application can then be invoked from the executive.4 Any executives invoked by the conference agents, and any applications invoked by those executives, are shared by all conferees.

picture(size 3.74in, postscript "figures/mm-replicated-small.vps-fig")

Figure 3. Fully replicated conferencing architecture.

picture(size 3.21in, postscript "figures/mm-infra-small.vps-fig")

Figure 4. Process structure on host Y.

Only one user may have the floor at any time. Therefore, all requests destined for each conferee's TheWAin must be intercepted. What the conference agent does with these requests depends on whether or not its user has control of the floor. If not, the conference agent is said to be in passive mode; it simply buffers the input requests and waits for the input to arrive from the controlling conference agent. If the user has control of the floor, the conference agent is said to be in control mode; it responds to input requests by asking its co-resident TheWAin for input.

When user input is received, the (controlling) conference agent broadcasts the input to all passive conference agents and passes it back to the requesting application. On receipt of the relayed input, each passive conference agent returns the input to its instance of the application, or buffers the input until a request for it is received.5 Thus, regardless of source (TheWAin or other conference agent), conference agents always pass user input on to their co-resident application. Each instance of the application proceeds to generate the same output, directly to their co-resident TheWAout.

The only change that needed to be made to existing software was the addition of a facility to TheWAin which permitted the conference agent to register itself to mediate all requests to open input streams. Not only was this change trivial in nature, but it provided a general ``intermediary'' facility that can be used in any similar situation — such as by monitoring programs, for example. Thus, the proposed implementation methodology, as manifested in TheWA, passed this particular flex test with flying colors.