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

On 10/6/14 15:38, Domenic Denicola wrote:
> From: Adam Roach [mailto:adam@nostrum.com]
>
>> Unfortunately, I fear that you may be responding to a partisan mischaracterization of the situation as conveyed to you out-of-band by an interested party, rather than the actual discussion that's taken place so far.
> I appreciate that might be possible :-/. Thanks for being patient if that turns out to be the case.
>
>
>> What you're seeing people push back against is a wholesale deprecation of an API that's been around in two independent implementations (three, if you go back to when Opera had its own implementation) for on the order of two years, and which has seen pretty broad adoption by webdevs.
>> Some of us don't want to break existing deployed applications. Others don't seem to think that this is important. That's the crux of the disagreement.
>>
>> With that clarification, I'd be grateful if you could share some thoughts on which side of the issue you would support.
> This API has no shipping *unprefixed* implementations, right?

As far as I believe, that's right. I'd suggest you check with the 
Ericsson folks working on Bowser to be sure.

> If so it seems clear that it'd be better to not ship a version that uses callbacks. That is, no standard navigator.getUserMedia should ever use callbacks.

As long as we never ship anything called navigator.getUserMedia, that 
retains compatibility. But because of the way people are calling this, 
anything named "navigator.getUserMedia" needs to support the current 
callback model, or it will break things. In other words, we either need 
to define "navigator.getUserMedia" to include callback semantics, or we 
need to burn the name forever.

> If there's a desire to support, say, a legacy navigator.webkitGetUserMedia that uses callbacks, in order to help existing applications work, that makes sense to me. It could be included in the standard (with that name), in the spirit of standardizing what's necessary for web-compat, despite it being distasteful. After all, if the goal is to avoid breaking existing deployed applications, then I would imagine it's much more important to standardize navigator.webkitGetUserMedia than to standardize navigator.getUserMedia. (I'm trying to find use-counter data to quantify how much more important, but regardless you can see why this is true.)

I agree with you on "distasteful," and would prefer to define it without 
naming it after a specific engine (you want to arm wrestle about whether 
it's "webkit" or "moz"?[1]). But I really don't feel strongly about it.

I would be surprised if there were any actual *production* code that 
calls webkitGetUserMedia directly without searching for it by other 
names. Perhaps the odd demo here or there, but actual services almost 
certainly want to run on both [2] current WebRTC-capable browsers. If 
you manage to turn up the data you're looking for, I would be keenly 
interested in what you find.

> What I'm objecting to so strongly is introducing a *new* API that uses callbacks, which no web code relies upon.
I don't believe that anyone has seriously proposed doing so in this 
thread, unless you're referring to the prefixing issue we're presently 
discussing (this, however, seems like a cosmetic variation rather than a 
legitimately new API).


____
[1] In case it's not clear, this comment is meant to be tongue-in-cheek, 
although the point about tastefulness stands.
[2] Or all three, depending on how you're counting Opera

-- 
Adam Roach
Principal Platform Engineer
abr@mozilla.com
+1 650 903 0800 x863