- From: Adam Roach <adam@nostrum.com>
- Date: Mon, 06 Oct 2014 14:43:50 -0500
- To: Domenic Denicola <domenic@domenicdenicola.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 10/6/14 11:41, Domenic Denicola wrote: > If there are shipping implementations in two or more browsers that are > callback-based, then that can be specified for interoperability as a > legacy API.... But it is still imperative to provide a promise > counterpart before the spec proceeds any further... Thanks for taking the time to weigh in! 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. If you go back to the proposal by the chairs, you'll see that what you suggest is exactly what is on the table; quoting Harald: "navigator.mediaDevices.getUserMedia gets changed to return a promise" (and) "[the equivalent legacy function] navigator.getUserMedia has callbacks." The push-back you're seeing isn't against Promises. There was unanimity on last week's call that Promises are strictly better than callbacks. 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. /a
Received on Monday, 6 October 2014 19:44:18 UTC