Re: Issue 81: Separating audio and video capabilities

DOMString kind is used in getUserMedia
so it was reused. Note that omitting it
Enables retrieval of all capabilities.

On May 19, 2014, at 12:06 PM, "cowwoc" <cowwoc@bbs.darktech.org<mailto:cowwoc@bbs.darktech.org>> wrote:

Robin,

I only think it's worth considering once you have 5 or more types. Right now you have 2 and I don't foresee having more in the future. When/if you end up with 5 or more you could switch over from one style to another and deprecate the original (but again, I doubt that will ever be necessary).

The only advantage of taking the type as argument is that you can fire the same logic against audio or video devices without the method in question knowing whether it is operating on audio or video. I agree there is theoretically a value in doing that, but in practice I can't think of a concrete use-case. Secondly, if you go down this road, I'd recommend removing getCapabilities() because you can emulate that behavior by simply invoke:

forEach (type in types)
  doSomething(getCapabilities(type));

Gili

On 19/05/2014 11:55 AM, Robin Raymond wrote:
Presumably it would be to allow expanded definition beyond audio/video in the future without expanding the surface of the API. If this could only ever be applicable to audio/video I would agree. I'm not certain (yet) that is true.

-Robin


<postbox-contact.jpg>
cowwoc<mailto:cowwoc@bbs.darktech.org>
May 19, 2014 at 11:51 AM
Again, why? What is gained by this approach over using separate methods for each type?

Gili

On 19/05/2014 8:49 AM, Peter Thatcher wrote:

<compose-unknown-contact.jpg>
Peter Thatcher<mailto:pthatcher@google.com>
May 19, 2014 at 8:49 AM
It can be an enum.

Received on Monday, 19 May 2014 16:24:42 UTC