Intent to implement and Ship in Blink-In-JS: WebRTC Promise-based API

[Harald Alvestrand]

Intent to implement and Ship in Blink-In-JS: WebRTC Promise-based API

Contact emails

h...@google.com

Spec

http://w3c.github.io/webrtc-pc/

http://w3c.github.io/mediacapture-main/getusermedia.html

Summary

The WEBRTC WG has had functions that call (succes, failure) callbacks. These are in present use.

It has recently (Q4 2014) added overloaded APIs that use Promises for the same functions.

This intent-to-implement is for supporting those additional APIs.

The work on adapter.js has proved that it’s possible to support these functions in ~20 lines of Javascript, using only Web-exposed APIs. We therefore propose to implement these using Blink-in-JS; this means that the work will involve support for returning a Promise from a Blink-in-JS function.

WebRTC in Blink-in-JS won't require any private script API.

We're planning to support Promise in Blink-in-JS in a way in which it doesn't leak JS objects of private scripts.

Motivation

The arguments for a promise-based style of API are well known. Customers are already querying us about when we will make the Promise-based API available.

Compatibility Risk

This change is positive for compatibility; Firefox already supports this feature.

The API is thought to be stable for WebRTC 1.0.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

crbug.com/499126

Link to entry on the feature dashboard

None (advice sought on creating one).

Requesting approval to ship?

Yes.

[Boris Zbarsky]

On 6/10/15 10:58 PM, 'Harald Alvestrand' via blink-dev wrote:
> The work on adapter.js has proved that it’s possible to support these
> functions in ~20 lines of Javascript, using only Web-exposed APIs.

But that's using the deprecated WebRTC API that is generally slated for
removal once the Promise-based APIs gain traction, right?

-Boris

[Douglas Stockwell]

What is the motivation to implement these APIs using Blink-in-JS? Is the C++ implementation non-trivial?

Are the callback versions of the APIs deprecated? Will they be removed? I don't see them in the latest spec.

[Harald Alvestrand]

The callback versions of the API are in section 4.3.3, "Legacy interface extensions".

The WG concluded that there was no consensus on setting a schedule for removing these, so for the foreseeable future, they're going to remain.

The motivation for using Blink-in-JS is not so much that the C++ implementation would be non-trivial, but that the Blink-in-JS implementation should be really trivial.

We do expect to see more cases of stuff being specified as "this older function can be done by calling these newer functions" as WebRTC rolls beyond 1.0 - a good Blink-in-JS support will make it easier to support these interfaces (none of which should be time critical - connection establishment and modification occurs on timescales of seconds, with frequencies in ops-per-minute, not milliseconds).

[PhistucK]

If I recall correctly, Blink in JavaScript is vastly meant to (re-?)implement deprecated or little used features or the like.

Since the Promise based API is going to be used going forward (rather than the callback based one), it seems to me that, if anything, it should be implemented natively (as a full blown supported and up to date feature) and that the callback based API should actually be implemented in Blink in JavaScript.

Besides, what do you intend to do?

Will getUserMedia({...}, success, error) return undefined and getUserMedia({...}) return a Promise? Basically, working around the WebIDL/binding limitation by using JavaScript?

If so, that sounds pretty hacky to me.

Also, if you are changing APIs, you should unprefix them. It has been (far too) long enough now, I think.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Domenic Denicola]

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of PhistucK

> If I recall correctly, Blink in JavaScript is vastly meant to (re-?)implement deprecated or little used features or the like.
> Since the Promise based API is going to be used going forward (rather than the callback based one), it seems to me that, if anything, it should be implemented natively (as a full blown supported and up to date feature) and that the callback based API should actually be implemented in Blink in JavaScript.

+1.

> Also, if you are changing APIs, you should unprefix them. It has been (far too) long enough now, I think.

Please leave any callback-based versions prefixed.

[Harald Alvestrand]

phistuck, I think you need to read the spec again wrt return values.

The WG has decided to specify the functions as overloads, where one overload returns void, and the other overload returns a promise. This has pointed out an unclear point in the spec, leading to a restriction in the blink code generator, but the WG has to decide on this.

If you think there's an issue, raise it as a spec bug.

As to what blink-in-JS is useful for: I don't think there's consensus on that.

To me (not a core developer), it's just another programming language; I want to use the programming language that minimizes implementation + maintenance effort.

[Domenic Denicola]

From: Harald Alvestrand [mailto:h...@google.com]

> Re prefixing: Apart from getUserMedia, the calls in this intent-to-implement were never prefixed (they're functions on RTCPeerConnection).
>
> I'll file another intent-to-implement to unprefix RTCPeerConnection (and a third one on unprefixing navigator.getUserMedia).

Can we just leave webkitRTCPeerConnection alone and have the unprefixed RTCPeerConnection not have all the callback methods?

[Harald Alvestrand]

Re prefixing: Apart from getUserMedia, the calls in this intent-to-implement were never prefixed (they're functions on RTCPeerConnection).

I'll file another intent-to-implement to unprefix RTCPeerConnection (and a third one on unprefixing navigator.getUserMedia).

[PhistucK]

We need use counter data for that (and I do not think we can gather that, how can you gather data about an API that is not implemented? :(), but I believe this will not work, because developers are using the callback based methods with and without prefixes at once.

Like navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia; and so on, probably with the other APIs/constructors as well.

Unless they check navigator.getUserMedia.length perhaps, but I wonder what the length will be with these overloads... 1 or 3? Probably 3. For a unprefixed API that only supports the Promise based API, this will indeed get them the right results... as long the the function never changes to have more arguments.

☆PhistucK

[Domenic Denicola]

From: PhistucK [mailto:phis...@gmail.com]

> I believe this will not work, because developers are using the callback based methods with and without prefixes at once. Like navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia; and so on, probably with the other APIs/constructors as well.

Ah yes, you are correct.

In any case, I hope we have an aggressive plan for deprecating and removing the callback-based overloads over time, based on use-counter data.

[Kentaro Hara]

> If I recall correctly, Blink in JavaScript is vastly meant to (re-?)implement deprecated or little used features or the like.
> Since the Promise based API is going to be used going forward (rather than the callback based one), it seems to me that, if anything, it should be implemented natively (as a full blown supported and up to date feature) and that the callback based API should actually be implemented in Blink in JavaScript.

As to what blink-in-JS is useful for: I don't think there's consensus on that.
To me (not a core developer), it's just another programming language; I want to use the programming language that minimizes implementation + maintenance effort.

According to the guideline we have agreed on 6 months ago, implementing a new feature is also in a radar of Blink-in-JS.

https://www.chromium.org/blink/blink-in-js

Quoted:

(**) The fact that we’re lowering the priority of Blink-in-JS means that we are going to be conservative about accepting your Intent-to-Implement. It is important to consider if your Blink-in-JS work has higher impact than other projects you could work on alternately. The Intent-to-Implement must provide clear advantages of why you think it is important for Blink to implement the feature in Blink-in-JS. For example, the following Intent-to-Implements look appealing:

• I need to implement MediaControls for Android. There are two options for us: implement it in C++ or implement it in JS. Given that MediaControls is a self-contained and high-level feature that can be developed on top of existing web-exposed API, I propose to implement MediaControls in Blink-in-JS. It is easier to develop and maintain.
• XMLViewer is already written in JS and it is invoked using direct V8 APIs. Given that Blink-in-JS has a safer mechanism to run JS in Blink, I propose to move XMLViewer to Blink-in-JS.
• I plan to make a substantial restructuring of the rendering system for performance. I noticed that marquee-specific code in the rendering system prevents us from making the restructuring. Given that marquee is an out-dated feature, I want to just factor out the implementation to Blink-in-JS instead of supporting the marquee-specific code in the new rendering system.

 

--

Kentaro Hara, Tokyo, Japan

[Daniel Bratell]

On Thu, 11 Jun 2015 05:55:01 +0200, 'Harald Alvestrand' via blink-dev <blin...@chromium.org> wrote:

The motivation for using Blink-in-JS is not so much that the C++ implementation would be non-trivial, but that the Blink-in-JS implementation should be really trivial.

There is a certain overhead of Blink-in-JS in resource usage which should also be a factor. I don't know how large that resource usage is but maybe someone else does. I would love some numbers.

/Daniel

-- 

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Harald Alvestrand]

Daniel, do you have even ballpark numbers for that overhead?

It's nice to see what orders of magnitude we're dealing with here.

(FWIW - it's well known that large parts of Firefox' APIs are implemented in Javascript, and I've heard rumours that the same is true for Edge. Blink-in-JS proves that we can do it; we need to know what the tradeoffs are.)

[Elliott Sprehn]

Is there a patch we can discuss this over? It's hard to understand if Blink-in-JS is really the right thing for this feature without seeing some code.

Also are there any other modules/ that depend on Blink-in-JS yet?

[Kentaro Hara]

Also are there any other modules/ that depend on Blink-in-JS yet?

As far as I know, no. The current substantial users of Blink-in-JS are only <marquee> and XMLViewer.

[Harald Alvestrand]

There's a bit of an unfortunate sequence in getting to a patch - because the proposal depends on adding a bit of functionality to Blink-in-JS (returning Promise), we have to have that functionality before we can have a working patch.

I could try to make up a fake patch....

[Jochen Eisinger]

Why are you planning to implement the new API on top of the old API and not the other way round?

I'd be somewhat surprised if it was less code to implement this in Blink-in-JS compared to just adding in the bindings (as you'll need to add anyways).

Blink-in-JS at the very least creates a new context which costs you about 200k memory + however long it takes to create it (it's more or less the same as creating an iframe).

I'd rather not have new Blink-in-JS features. If you want to ship some JS code that behaves like a polyfil (i.e. directly runs on top of the existing DOM API), I'd encourage you to try V8 extras.

best

-jochen

[Harald Alvestrand]

Summary of thread so far:

Re old and new APIs:

- The spec says we'll have both old and new APIs. So that's what we need to do.

- We'll need to install counters so that we can argue to the standards groups that the usage of the old API is so low, we can take it out. But first we have to measure both.

Re implementation strategy:
There are now 3 options:

- Blink-in-JS

- v8 extra

- straight-up C++

The last is clearly the least controversial, but probably the most lines of code.

I'll go think about this some more and come up with some arguments for picking one.