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

From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com] 

> I'm trying to figure out a pull-request for this. It seems to me that burning the name forever is what Domenic is suggesting here.

Agreed, although I would phrase it as "don't introduce any new callback-using APIs," with the understanding that "new" means "unimplemented in any browsers." webkitGetUserMedia and mozGetUserMedia are implemented, but getUserMedia is not implemented, and so adding it to implementations would be new.

>> 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.
>
> Me neither, but since there are several browsers on webkit, some of which we hope will implement this in the future, it probably makes sense to use navigator.webkitGetUserMedia as a primary name in WebIDL etc, but with a caveat in prose that implementations may choose to implement it as navigator.mozGetUserMedia instead?

There's two separate questions here:

1. Does the working group wish to standardize callback-returning `navigator.{something}GetUserMedia` for web-compat? Or would you prefer to leave that as proprietary nonstandard functionality that a few browsers implement, but is not recommended for new browsers? Both positions seem tenable to me. The former has the benefit of allowing more sites to work unmodified; the latter gives us a cleaner web going forward.

2. If you do want to standardize on something, what should it be? The three choices seem to be: `navigator.getUserMedia`, `navigator.mozGetUserMedia`, and `navigator.webkitGetUserMedia`. Since this is being done solely for web-compat it seems clear that the unprefixed variation cannot be *more* compatible than the other two, only less. Adam's earlier message states:

> 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.

Let's frame it this way. Let:

U = # of sites that will work unmodified in all browsers, if all browsers implement navigator.getUserMedia
W = # of sites that will work unmodified in all browsers, if all browsers implement navigator.webkitGetUserMedia
M = # of sites that will work unmodified in all browsers, if all browsers implement navigator.mozGetUserMedia

It's clear that U <= W and U <= M. I conjecture that U < M < W, whereas Adam conjectures that U = M = W (omitting "the odd demo here or there"). Nobody has conjectured that M > W, but it's certainly possible. I'm working to find some data, but in the meantime the safest thing to do, if the working group wishes to standardize something in the name of making more sites work unmodified, seems likely  to be standardizing navigator.webkitGetUserMedia and navigator.mozGetUserMedia.

Actually, seeing the other subthread Anne's continuing on this morning, there's a third question:

3. If the working group standardizes on a callback-returning navigator.webkitGetUserMedia and navigator.mozGetUserMedia in the name of making existing sites work unmodified, should the working group add a warning and/or deprecation notice to the spec? Should browsers emit deprecation warnings upon use?

Received on Tuesday, 7 October 2014 15:59:07 UTC