[timingobject] Run TimingProvider code in a separate JavaScript realm

tidoust has just created a new issue for 
https://github.com/webtiming/timingobject:

== Run TimingProvider code in a separate JavaScript realm ==
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](http://w3c.github.io/webrtc-pc/#identity-provider-interaction).
 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:

1. 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.
2. 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.

What about it?

See https://github.com/webtiming/timingobject/issues/10

Received on Wednesday, 22 July 2015 16:33:47 UTC