Re: [Bug 26243] Do we need getUserMedia() on MediaDevices?

While I agree that the cost/benefit of making this change is not 
necessarily the best in the world, I am afraid of the precedence you're 
about to set here.

I have no sympathy for anyone who complains about API breakage while 
building on top of a moving target and last I checked, the final version 
of Media Capture and Streams has yet to be published. Until it is, our 
sole goal should be to deliver the best API possible, period. Otherwise 
you will end up with a sub-par API and everyone will suffer in the long run.

Gili

On 22/08/2014 2:24 PM, Chris Wilson wrote:
> Although I'm empathetic to your attempts to clean up the API, I'd 
> offer the advice that this probably is too well-established to 
> advocate removal.  You could offer it additionally, but every bit of 
> getUserMedia code, everywhere, will break with that change otherwise.
>
> It *is* easy to add the new location; the problem is that you need to 
> make that change in every bit of code that's already out there.  I 
> think it would be fine to map it additionally in to 
> navigator.mediaDevices, but I don't think you're going to find browser 
> vendors very excited to break current code in this way.  From my 
> experience with Web Audio, there would be a lot of complaints.
>
>
> On Fri, Aug 22, 2014 at 10:06 AM, Martin Thomson 
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>
>     On 22 August 2014 06:55, Dominique Hazael-Massieux <dom@w3.org
>     <mailto:dom@w3.org>> wrote:
>     > While esthetically I can understand the change, I don't think
>     aesthetics
>     > have sufficient values to justify the cost of explaining to
>     thousands of
>     > developers that their existing
>     >   navigator.getUserMedia = navigator.webkitGetUserdia ||
>     > navigator.mozGetUserMedia;
>
>
>     The existing code looks like this:
>
>     navigator.getUserMedia = navigator.getUserMedia ||
>     navigator.webkitGetUserMedia || navigator.mozGetUserMedia;
>
>     But what about other browsers?  Don't they get their prefixes too?
>
>     And it's easy to change this hack to add the new location.
>
>     I think that users with prefixes in their code understand that their
>     code will be broken and are willing to update.  We can leave a shunt
>     in place at the prefix for some period, but I don't like the
>     implication that a half-considered/half-designed feature determines
>     the state of the browser in perpetuity.
>
>