- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Mon, 03 Feb 2014 14:44:27 -0500
- To: Cullen Jennings <fluffy@iii.ca>, Martin Thomson <martin.thomson@gmail.com>
- CC: Robert O'Callahan <robert@ocallahan.org>, Harald Tveit Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2/3/14 2:05 PM, Cullen Jennings wrote: > On Feb 3, 2014, at 10:32 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > >> These are all fine, but this offers little material support for the >> use of constraints in this specific use case. Is there anything wrong >> with: >> >> app: get me a 96kHz recorder >> browser: can't do that > le. > I’d be fine with that but that is not what the discussion is about. The discussion is if the app can control the setting or even discover what is being provided. What I sent to to roc was "The constraint API has moved to support more or less exactly what you propose below but calls it a setting. " I agree, often capabilities + settings can do what you need without constraints. To put it in context here, the conversation we are discussing > > app: get me a 48KHz recorder > browsers: thinks to itself that it can’t do but decides that the browser know better than the app developer what the app app really needs and decides to say just take the app data from 22KHz recorder and pretend it it was from a 48KHz recorder > > I agree that an application could solve this problem with settings, or with capabilities, or with constraints. I’m just saying that you need one of those three. Great, I vote for settings then because settings are just dictionaries. Being able to read the settings from the resulting object as the same dictionary that was used as a constructor argument seems reasonable to me. We don't need the complex semantics of Constrainable for this. .: Jan-Ivar :.
Received on Monday, 3 February 2014 19:44:50 UTC