Re: Strawman Promises consensus position, based on Thursday's telechat

Adam's message covers my position on this issue well. The fact that the
existing getUserMedia API is prefixed doesn't mean we can just ignore the
existing uses of it.

I think we're talking about a paragraph of text that shows how the existing
API can thunk to the new API, so I don't really understand why this so
controversial.

On Tue, Oct 7, 2014 at 8:31 AM, Adam Roach <adam@nostrum.com> wrote:

>  On 10/7/14 10:20, Anne van Kesteren wrote:
>
> On Tue, Oct 7, 2014 at 5:12 PM, Eric Rescorla <ekr@rtfm.com> <ekr@rtfm.com> wrote:
>
>  It could be, but at the cost of inconveniencing users in the name of
> specification purity.
>
>  navigator.getUserMedia(), unprefixed, never shipped in any
> implementation. Removing it therefore does not inconvenience
> developers. What implementations do with their proprietary
> implementations is up to them. And implementations having proprietary
> implementations should not put pressure on the specification process
> (unless it turns out we have to standardize one of the prefixed
> variants, but that seems unlikely long term).
>
>
> That's pretty tone-deaf when you consider the implications for new
> implementations.
>
> Not to pick on anyone, but (because they provide a good, real-world
> example), let's imagine Apple plans to ship WebRTC in some near-future
> version of Safari. If we proceed as you propose, they'll have effectively
> two choices:
>
>
>    1. Implement to spec (mediaDevices.getUserMedia), and have literally
>    nothing that's already deployed work, or
>
>     2. Implement from some inferred behavior about webkitGetUserMedia (or
>    mozGetUserMedia) that is not defined in the spec, and have existing
>    applications work just fine.
>
>
> That seems untenable to me. If new implementations need to implement an
> interface for compatibility with the deployed corpus of webapps, then it is
> incumbent on the specification to document that interface in some form.
>
> /a
>
>
>