- From: Francois Daoust <fd@w3.org>
- Date: Fri, 10 Apr 2015 14:56:19 +0200
- To: public-webtiming@w3.org
Hi Multi-Device Timing group, The Timing Object spec defines the core timing object but leaves out the core mechanisms used to connect it to online timing resources. I'm not sure about the best way to proceed, but I'm sure you do, so thought I'd throw out mumblings and questions to gather input :) The spec describes two synchronization mechanisms [1] for the multi-device scenario: - "update synchronization" which handles vector propagation, covering the sending of vector updates from a client to the online timing service on one hand, and the broadcasting of the updates received by the online timing service to all connected clients on the other hand. - "clock synchronization" needed to synchronize the local client clock with that of the online timing service. My understanding is that different protocols can be used here in theory. For instance, HTTP long polling could perhaps be used to handle "update synchronization" and NTP could be used for "clock synchronization". A new dedicated protocol could also be defined. Messages exchanged over some Web Socket connection could also work as well. Is that roughly accurate? If so, how much flexibility do we want here? More precisely: 1. How many remote endpoints are needed to connect a timing object to an online timing resource? The current "src" attribute assumes that the same communication channel will be used for both mechanisms. Is there a need to relax that constraint and e.g. allow users to provide a URL for "update synchronization" and one for "clock synchronization"? 2. Will the spec mandate mechanisms? For instance, as opposed to image format supports, it would not be that easy for Web authors to support different types of online timing resources in practice for instance, since supporting additional types would require the backend to support additional protocols. To achieve interoperability and ease of use, it seems important to mandate default mechanisms common to all implementations. 3. To ease implementation and make it easy to create polyfills, and implement online timing resources, building the mechanisms on top of a protocol already implemented by Web browsers and easy to support on servers seems like a good idea, in other words on top of Web Sockets since we need a dual-way communication channel. It could also make our life easier from a specification perspective. Developing a new protocol might lead to better results but seems harder to achieve than a higher level approach that "just" specifies exchanges over a Web Socket connection. 4. If multiple mechanisms are possible, how can a Web author tell if a particular mechanism is supported? In the end, I'm proposing to stick to Web Sockets and define mechanisms in terms of messages exchanged on top of such a channel. One possibility in a hypothetical rosy future could be to allow the creation of a timing object from an already established communication channel, meaning from an object that has the semantics of a Web Socket (an onmessage EventHandler and a send method in other words). That would make it possible to reuse the same communication channel for different purpose (although we would need some way to filter out non-timing messages) as well as to address other use cases such as direct peer-to-peer connections between devices, or use of a WebRTC data channel between a client and a server (I vaguely remember having heard that this was possible). I'm not suggesting that we do that right now (and that's out of scope looking at the charter) but that would be relatively easy to add if the initial spec defines the mechanisms in terms of "message exchanges" over some communication channel. Does that make sense? Francois. [1] http://webtiming.github.io/timingobject/#distributed-synchronization
Received on Friday, 10 April 2015 12:56:28 UTC