Intent to Deprecate and Remove : Remove Non-standard APIs on MediaStreamTrack.

[박열]

Primary eng emails

h...@chromium.org

Summary

The goal is to deprecate (and eventually remove) the MediaStreamTrack.remote attribute.

Motivation

This method is no longer part of the spec.

Compatibility Risk

The compatibility risk is low. 

MediaStreamTrack.remote attribute was removed w3c part of the spec and very low count.

[#321] Remove track attributes "remote" and "readonly" : https://github.com/w3c/mediacapture-main/pull/321

Usage information from UseCounter

Usage is low than 0.0001%:

https://www.chromestatus.com/metrics/feature/popularity#MediaStreamTrackRemote

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=598704

Entry on the feature dashboard

https://www.chromestatus.com/features/5698636931399680

Requesting approval to remove too?

Yes

[TAMURA, Kent]

LGTM1.

--

TAMURA Kent
Software Engineer, Google

[Philip Jägenstedt]

LGTM2, thanks for tackling this!

Note that you can use your own email for "primary eng emails", or delete that section entirely if you're the only person working on it.

[Jochen Eisinger]

lgtm3

[PhistucK]

The intent mentions "APIs" (plural), are you deprecating anything other than MediaStreamTrack.remote?

☆PhistucK

lgtm3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rick Byers]

This will have a deprecation warning for at least one milestone prior to removal (as it typical for most removals), right?

Assuming that's the case then LGTM from me also :-)

[박열]

It's just title :)

This issue says only about |remote|.

but tracking bug is |remote| and remnants of |readonly|.

|readonly| was removed at long time ago. 

2017년 1월 24일 화요일 오후 11시 29분 22초 UTC+9, PhistucK 님의 말:

☆PhistucK

lgtm3

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

[daniel.l....@gmail.com]

[daniel.l....@gmail.com]

On Thursday, January 19, 2017 at 6:45:43 PM UTC-8, 박열 wrote:

[daniel.l....@gmail.com]

[daniel.l....@gmail.com]

☆PhistucK

lgtm3

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

[Harald Alvestrand]

In my opinion, the stats on usage of "remote" don't warrant a warning.

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

[Philip Jägenstedt]

It's true that when usage is this low, a deprecation message is fairly unlikely to be seen by anyone. But we want web developers to be able to trust our process, so that anything that can be discovered by paying attention to the console is discovered before the actual removal. In this case, would there be a benefit in making the removal sooner? If so, perhaps we can merge the deprecation message back to M57 and then remove immediately on master?

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

[Harald Alvestrand]

Deprecating in M57 would make sense to me. That CL looks as if it's very unlikely to cause harm to anything.

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

[Philip Jägenstedt]

I was looking at RTCPeerConnection's getLocalStreams and getRemoteStreams and wondered if this removal should be tied together with those? Although the code isn't entirely straightforward, presumably the get*Streams() methods should consult the very same underlying information?

This deprecation was reverted for unrelated reasons, but can this question be pondered before trying again?

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

[Harald Alvestrand]

Let's kill'em one at a time.

The reason for removing the "remote" attribute from the specs for tracks is that it was increasingly clear that the many variants of streams made the "local/remote" distinction rather unclear (is a track sourced from a <video> tag playing a dynamically-loaded video remote or local?).

getLocalStreams and getRemoteStreams is a much more clear-cut distinction: Is the stream attached locally and sends data to the remote end, or is it sourced from the PeerConnection and receives data from the remote end? In the days of "addStream", it could never be both.

The reason these were removed from the spec was that we attempted to switch the spec to deal with tracks as the fundamental unit, and that this should be mediated via getSenders() and getReceivers() - http://w3c.github.io/webrtc-pc/#rtcpeerconnection-interface-extensions

These functions haven't been implemented in Chrome yet. So it's still far too early to start thinking about deprecating get*Streams.

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

[Philip Jägenstedt]

Thanks Harald, sounds like these APIs aren't connected in the way I imagined. Gecko has getLocalStreams and getRemoteStreams but doesn't have the remote attribute, so this is a "configuration" that exists and presumably makes good-enough sense.

Please carry on :)

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