The proposed TimingProvider interface is intended to allow the inclusion of code maintained by a third-party timing provider. This code would typically need to create a communication channel to a backend server under the control of the timing provider.
As things stand, this would require the timing provider to enable CORS for arbitrary origins, which does not seem to be a good thing.
WebRTC has a similar need for Identity Providers. In practice, WebRTC requires the user agent to instantiate a separate JavaScript realm (some sort of worker in short) that operates in the origin of the loaded JavaScript and to load the JavaScript provided by the Identity Provider there. It could be a good idea to apply the same concept to the Timing Object specification.
This would have the added benefit that the code provided by the timing provider would not be able to mess with the code owned by the origin of the Web application.
Perhaps even more importantly, this would mean that the code of the timing provider would run in its own "thread", meaning that the user agent would be able to interact with it e.g. to retrieve a new timestamp to coordinate video playback in the background (with the current proposal, the user agent would need to queue a task to invoke any method on the TimingProvider object)
In practice, this would require to:
define a TimingProviderRegistrar interface with a "register" method. The user agent would expose one instance of that interface to the TimingProvider code and the timing provider code would call the register method when it loads.
use the URL of the timing provider code rather than a TimingProvider object to associate a TimingObject with a timing provider.
One possibly important drawback is that, since the TimingProvider object would no longer be exposed to the Web application, additional methods that the timing provider could expose such as mechanism to create/destroy an online timing resource, and authenticate the user, would require out-of-band commuications between the Web Application and the timing provider.
The proposed
TimingProviderinterface is intended to allow the inclusion of code maintained by a third-party timing provider. This code would typically need to create a communication channel to a backend server under the control of the timing provider.As things stand, this would require the timing provider to enable CORS for arbitrary origins, which does not seem to be a good thing.
WebRTC has a similar need for Identity Providers. In practice, WebRTC requires the user agent to instantiate a separate JavaScript realm (some sort of worker in short) that operates in the origin of the loaded JavaScript and to load the JavaScript provided by the Identity Provider there. It could be a good idea to apply the same concept to the Timing Object specification.
This would have the added benefit that the code provided by the timing provider would not be able to mess with the code owned by the origin of the Web application.
Perhaps even more importantly, this would mean that the code of the timing provider would run in its own "thread", meaning that the user agent would be able to interact with it e.g. to retrieve a new timestamp to coordinate video playback in the background (with the current proposal, the user agent would need to queue a task to invoke any method on the TimingProvider object)
In practice, this would require to:
TimingProviderRegistrarinterface with a "register" method. The user agent would expose one instance of that interface to the TimingProvider code and the timing provider code would call theregistermethod when it loads.One possibly important drawback is that, since the TimingProvider object would no longer be exposed to the Web application, additional methods that the timing provider could expose such as mechanism to create/destroy an online timing resource, and authenticate the user, would require out-of-band commuications between the Web Application and the timing provider.
What about it?