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

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

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

What I'm objecting to so strongly is introducing a *new* API that uses callbacks, which no web code relies upon.

Received on Monday, 6 October 2014 20:39:32 UTC