Re: Constraints and MediaRecorder

On 2/4/14 12:43 AM, Harald Alvestrand wrote:
> On 02/03/2014 08:55 PM, Jan-Ivar Bruaroey wrote:
>> On 2/3/14 2:35 PM, Harald Alvestrand wrote:
>>> On 02/03/2014 06:32 PM, Martin Thomson 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
>>>>
>>>> Because that's what is being suggested.
>>> It seems to me more complex to do:
>>>
>>> app: get me a 96khz recorder
>>> browser: can't do that
>>> app: get me a 80khz recorder
>>> browser: can't do that
>>> app: get me a 48khz recorder
>>> browser: can't do that
>>> app: get me a 44.1khz recorder
>>> browser: ok, here's one
>>>
>>> than to do
>>>
>>> app: get me a recorder absolutely above 40 khz, prefer one above 80 khz
>>> browser: ok, here's an 88.2khz recorder
>> The first one is simpler because the second one is a new language.
> But since we already have this language in GUM, it's no longer a new
> language.

Yes, but it is still not *simpler*. It is overkill and lacks proven generalization outside of gUM. For instance, the terrible asymmetry that the optional keys are in an array, and that order matters, is of absolute zero use here, then add that you cannot use dictionaries, which means you cannot use webidl to describe your API fully, and have to revert to prose for a significant part of your spec, making it look like a wall of text.

If we're going to have a debate about language in web standards and about what's simple, I think we have the wrong audience here, and we should listen carefully to feedback from DOM and language people, and discard feedback that trivializes the subject of language as a list of names and values.

> (I may have been too subtle. In the probing approach, you ended up with
> a 44.1 kHz recorder because that's what the application knew how to
> probe for.
> In the "ranges of options" approach, you ended up with an 88.2 kHz
> recorder because the application did *not* probe for specific values.)

Thanks for clarifying. I should equally point out that mine finds the right value also then:

>> I prefer: app: get me a 96khz recorder browser: keep dreaming, here's 
>> 88.2khz, best I can do.

.: Jan-Ivar :.

Received on Tuesday, 4 February 2014 15:30:20 UTC