Architecture
Introduction
In line with the MTCG Charter (http://webtiming.github.io) we propose a strict client-server architecture for multi-device timing. In particular, we propose to introduce a TimingObject in HTML that may connect with an online timing resource. The TimingProtocol describes the communication between TimingObjects and online timing services. Relevant considerations concerning this architecture are presented in the appendix below.
The above figure illustrates three Web clients hosted by three different devices, say a laptop, a smartphone and a tablet. These three Web clients each have a TimingObject connected to a single, online, multi-device timing resource (RED). For example, the online timing resource could be used as basis for shared media control, allowing multiple clients to operate in synchrony. This way, a laptop could present a video, the smartphone could present the audio track, and the tablet could present controls, progressbar, and timed extra information. If the timing resource is requested to pause, all connected clients pause in unison. Connecting a TimingObject to an online timing resources could in principle be as simple as specifying the timing resource URL as the source attribute of the TimingObject.
Scope
To implement the above scenario, two main challenges must be addressed.
- ensure that TimingObjects at different devices are always synchronized with the online timing resource.
- ensure that different UI components are always synchronized with local TimingObjects.
MTCG aims to address both these problems. To address the first problem, the group shall draft a protocol specification for synchronization of multi-device timing resources. To address the second problem MTCG shall work to simplify integration with existing timing concepts, by providing bug reports, suggesting API changes or functional extensions.
Definitions
Timing Service
A timing service is a Web service specializing in hosting timing resources on behalf of timing-sensitive, multi-device applications.
Timing Resource
Timing resources are online objects representing various application-level timing concepts, such as clocks, timeouts, stop-watches or media controllers. Timing resources are true objects on the Web, identified by URL’s and hosted by timing services. Timing resources are created and used by Web applications in order to support timing-sensitive execution in multi-device applications.
TimingObject
As indicated in the above example, the TimingObject may specify a source attribute identifying an online timing resource. If so, the TimingObject will act as a representative to an online timing resource. This way, control operations such as play or pause will be forwarded to the timing service. Effects can then be propagated equally to all connected clients. The TimingObject fully encapsulates the complexity of multi-device operation and leaves the programmer to interact only with local objects. Indeed, the TimingObject provides a common basis for various forms of timed operation and provides the same API for local and online timing resources. This ensures that time-sensitive application components may be used in offline/single-device or online/multi-device scenarios without modification.
Client-Server Architecture
We adopt the classical client-server architecture of the Web. In the Web environment servers are reliable and stateful, whereas clients are stateless and may joins/leaves a Web application any time. In a pure client-server model, clients communicate via servers and clients operate independently of other clients.
To realize multi-device timing within the client-server model, we define timing resources (e.g. clocks, timeouts, stop-watches, controllers) to be proper objects of the Web, identified by URL’s and hosted by servers. In order for clients to make use of timing resources, they connect, synchronize and interact with server-side timing resources. Clients may connect and disconnect at any time, without affecting other clients. Timing resources continue to exist even if no clients are connected. With stateless clients, a reload is equal to a disconnect followed by a new connect. Interaction with timing resources is achieved by requesting changes to server-side objects, and all connected clients are equally notified of such effects.
Client-side Synthesis
Modern Web pages are synthesised on the client side, from a set of resources. Typically, the initial loading of the main HTML document is followed by loading of referenced resources, such as scripts, images, videos, or even full HTML resources within iFrames. Furthermore, dynamic Web pages, such as live sports, are increasingly built dynamically by JavaScript based on live data sources. Client-side synthesis is also driven by user interaction or timed operations. Multi-device timing fits perfectly within this model, as multi-device timing resources are simply a new type of dynamic resource, a driver for timed synthesis.
Also, with respect to precisely timed operations in multi-device applications, client-side representation of timing resources and client-side synthesis is crucial. The alternative is synchronization through “as-fast-as-possible” data transfer (e.g., broadcast, multicast or push). With this approach, precision is limited by differences in network delay. Furthermore, forcing servers to coordinate timed data transfer represents a suboptimal use of server resources as well as bandwidth capacity. In contrast, with client-side timing resources, precision depends on clock synchronization, and data transfer may be decoupled from presentation.
Minimize latency, maximize precision and scale
Multi-device timing in wide area networks is a challenging effort due to high network delay, and large differences in delay between different networks and links. The Web environment makes this even more challenging, with limited access to low-level communication, timing or scheduling primitives.
At the same time, a successful implementation of multi-device timing critically depends on reliably supporting high precision timing and high scale. This is feasible in a centralized Web architecture, but only as a result of a dedicated design effort. In other words, when designing a solution for multi-device timing, the distributed considerations have absolute priority.
The multi-device timing group will base its work on Shared Motion. It is a minimalist solution in communication and processing logic, successfully combining high precision and scale with conceptual simplicity and wide utility. Shared Motion is a generalization over clocks, stop-watches and media controllers.
Specialized Servers
Another characteristic of the Web environment is specialized servers and hosted services. Timing servers match this pattern as they are dedicated to hosting timing resources. This allows for highly efficient implementations. A major goal for timing servers is to support a high number of clients, yet remain responsive at all times. This goal can easily be compromised if the server also manages other tasks, such as providing access to other forms of application data. Scale is achieved in a hosted service by partitioning the load between multiple servers.
