Re: Object.Observe

Hi Ingar,

On 2015-12-10 10:49, Ingar Mæhlum Arntzen wrote:
> Hi Francois and all.
>
> I'm working with the timing provider interface and the spec currently defines Object.Observe as the mechanism to monitor state changes of the timing provider (i.e. skew, vector).
>
> This post [1] though indicates that O.O does not have a particularly bright future.
>
> Do you know anything about this?

Indeed, the proposal seems to have been abandoned. I do not know more than what is written in the post you mention.

However, what is needed for the spec is not Object.observe but rather the possibility that a Web browser can implement something like Object.observe internally to observe updates made to properties of a TimingProvider object. I still do not know whether that is easy or not, and still do not know how it could be described in the spec.

There are possible alternatives if such a mechanism turns out to be impractical, the main difficulty being that user objects cannot inherit from EventTarget, so events cannot be considered directly (although they would be a great fit!).

You mentioned callbacks. If TimingProvider objects are to run in a separate JavaScript realm (as discussed in issue 10), another possibility would be to replace the current TimingProvider interface by a native interface exposed on the global context of the JavaScript realm with appropriate "setSkew" and "setVector" methods. I find the use of methods less simple to grasp and more error-prone, but people might actually object that setting a property to alert the browser that it needs to adjust its clock is counter-intuitive as well.

In other words, the timing provider JS code would load in a separate realm and run code such as:

// Register the function called to process vector updates
timingProvider.registerUpdateCallback(function (vector) {
   // Update logic
});

// Set new clock skew
timingProvider.setSkew(2.0);

// Set new state vector
timingProvider.setVector({
   position: 4.5,
   velocity: 1.0
});

// Tell the browser that we're ready
timingProvider.setReadyState('open');


In terms of spec, this should look like the interfaces in WebRTC [2], with WorkerGlobalScope defined in WebWorkers [3]:

interface TimingProviderGlobalScope : WorkerGlobalScope {
   readonly attribute TimingProvider timingProvider;
};

callback UpdateCallback = void (TimingStateVectorUpdate vector);

interface TimingProvider {
   void registerUpdateCallback(UpdateCallback update);
   void setRange(unrestricted double startPosition, unrestricted double endPosition);
   void setReadyState(TimingObjectState state);
   void setSkew(unrestricted double skew);
   void setVector(TimingStateVectorInit vector);
};

This probably deserves more thoughts...

>
> Also, I'm not sure if there was a specific reason why O.O was suggested in the first place.

The goal was to reduce the number of actions that a timing provider needs to achieve to expose the current state vector and the clock skew to a bare minimum. With something like the observe mechanism, the timing provider only has to worry about setting two properties, which it would need to maintain internally in any case. Any other mechanism requires more actions on the part of the timing provider. More actions lead to bugs. Bugs lead to crashes. Crashes lead to suffering! :)

> For the first implementation (where both timing provider and timing object are user objects) I'm thinking that a basic callback mechanism should do. Would you agree?

Right. By definition, you only have access to user objects in JS, so you indeed need to take some liberty with the spec to implement the API! The above discussion on the JavaScript realm would also only make sense in a native implementation.

Francois.

>
> [1] http://www.infoq.com/news/2015/11/object-observe-withdrawn
[2] http://w3c.github.io/webrtc-pc/#sec.create-identity-proxy
[3] http://www.w3.org/TR/workers/#the-workerglobalscope-common-interface

Received on Thursday, 10 December 2015 17:24:31 UTC