In order to provide rapid semantic feedback in single-user applications, aspects of the presentation can easily leak into the application semantics as all the components are held on the same machine. But when the software is no longer running on a single machine in a distributed environment, one can no longer fudge the boundary and communications between the application and the user interface components as they are enshrined in the physical location and network connectivity. As a result, the issue of where the components reside is decisive in order to achieve rapid feedback.
In the Seeheim architectural model, the fast-switch is used as an optimisation feature to allow the application to communicate directly with the presentation and thus bypass the dialogue component (Section 3.2.1). In principle, all feedback could be routed through the dialogue component with more or less translation and interpretation on the way. But, in so doing, the dialogue component introduces a computational delay between the application and the presentation, thus reducing the pace of feedback. Arguably, this is not a problem for current single-user single-machine systems as they can easily perform several levels of processing and still achieve acceptable interactive response.
However, in collaborative systems, the shared data is likely to be stored remotely from the user’s workstation. So, instead of a computational delay there will be a network delay. Feedback delays are bound to occur and consequently affect the rate of feedthrough. Unfortunately, one cannot simply add an extra component like the fast-switch, as it too would have to sit remote from the data or remote from the interface. Computational components can be bypassed, but not space!
One can either accept that semantic feedback will be delayed or adopt a paradigm of mediated interaction, which offers instant local feedback to show that the user’s action has been recognised and subsequent semantic feedback when the effect has occurred remotely (Dix, 1995a). However, the latter solution will not be acceptable in situations where users demand direct manipulation interfaces.
5.5.1 Replication and Caching
Most solutions that aim at providing rapid feedback and increasing the availability of data involve some form of replication or caching. The objective is to bring the shared data closer to the users.
Caches are merely temporary repositories, which hold an ephemeral copy of the data at any instance in time. Each user interacts with local copies of the shared data on their workstation (figure 5.2a). Because the actual shared data is stored in a central repository, consistency can be easily maintained. Caching is widely used in the design of computer systems such as microprocessors to access recently used data. Similarly, a Web cache stores recently accessed information by users.
User 1 Application 1 Cache 1 User N Application N Cache N User 1 Application 1 Replica 1 User N Application N Replica N (a) Shared data Workstation N
Workstation 1 Workstation 1 Workstation N
(b)
Figure 5.2 (a) Caching and (b) Replication
A Web cache is basically a dedicated computer system that monitors, retrieves and stores Web object requests. So, when users request the same objects or Web sites, the local cache sends out information to them. Cached objects eliminate the need for multiple hops on the Internet route, thus reducing the delay in the service and improving the response time. The higher the frequency of users requesting the same site, the more effective the cache is.
Replicas, on the other hand, are valid full copies of the real data that are stored locally, thus they are more persistent than caches. However, it is more difficult to maintain data and interface consistency, as replicas have to communicate between each other on a peer-to- peer basis. Replicas are synchronised by sending user input from each workstation to each replica (figure 5.2b). Multiple points of updates may lead to race condition and potential data inconsistency. For example, if a user deletes a selected object in a WYSIWIS group drawing program while another user is changing the selection to a different object, inconsistent interfaces may occur if the events arrive at each workstation in a different order.
The traditional approach to replication in distributed systems has been transparency. Race conditions are avoided by maintaining consistency across the different copies of the data through complex synchronisation algorithms. If inconsistencies still persist, a possible solution is to rollback the replica(s) and re-execute the events in temporal order (Satyanarayanan et al., 1990). However, this policy is unacceptable in collaborative interfaces because the display screens would already have been updated. Consequently, alternative solutions based on transforming updates to prevent rollback have been developed (Bentley et al., 1994).
When rapid feedback is not the major concern, concurrency control mechanisms, such as locking or floor control can be applied to prevent race conditions altogether or at least tolerate them (Dix et al., 1993). Real-time synchronous updates may however demand special-purpose algorithms.
Any control mechanism requires meta-data, for example, to record who has the lock on which object. The meta-data itself has similar issues as the real data. It can either be maintained in a replicated fashion by using complex distributed algorithms, or more commonly maintained using a central server. When the data is stored centrally, the same server may deal with both the data and the meta-data, as is the case in traditional databases. However, a separate locking server can also be used. For example, the UNIX file system has no in-built locking mechanism; instead applications request locks on remotely stored files from a special process, the lock daemon.
In situations where off-the-shelf locking is not available or where the locking supplied is unsuitable, application developers are forced to use their own ad hoc locking mechanisms. This is usually the case with Web-based cooperative applications.
5.5.3 Notification
Delayed feedback causes problems, but delayed feedthrough is even more problematic in a distributed environment. No amount of careful placement of components can change the fact that the user making a change is a long way from other users who see the effects of that change. Although a lower pace of feedthrough is more acceptable than the feedback rate (see Section 4.1.3), what is not acceptable is the fact that changes made by a user are never reflected on other users’ interfaces or only do so after a long delay. Notification mechanisms are therefore necessary to provide timely feedthrough, as discussed in Section 5.4.4.
The question of meta-data will arise here too independent of the notification strategy adopted. Information such as what objects are being managed and who wants to know about which object will be associated with this meta-data. Again, this can be stored in either a centralised or a replicated fashion.
5.5.4 Different kinds of remoteness
When remote data is accessed in a single-user system by using traditional client-server techniques, the distinction between local and remote is clear. However, in a cooperative application, the difference gets blurred because users have their own interpretation about what is local and what is remote. A user’s own machine can be considered to be local while data stored or updated on another user’s machine may be regarded as being remote. So, if semantic feedback relies on the data held at another user’s machine, the feedback delays will be as long as if the data was held centrally, perhaps longer as central servers may provide a better response.
The situation gets even more complicated when using the Web as an infrastructure. Each user may be accessing several Web servers as well as other central servers such as databases. To a certain extent, the Web makes the physical location of the data unimportant, except insofar as the location affects the response time. However, the physical location is very important, especially when using Java applets. The security mechanisms of Java only allow the applet to access Internet services lodged on the same machine as the Web server that supplied the applet.
There are in fact four kinds of ‘remote’ application for the Web: (a) another user’s client
(b) the Web server for the current page
(c) a different server on the same machine as the current Web server (d) a server on a different machine
The placement decisions for the Web therefore do not stop at local versus remote, or even client versus server. The decision about where server software is placed is intimately related to the techniques used to implement client software.