Re: Constraints and MediaRecorder

On Mon, Feb 3, 2014 at 3:00 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Tue, Feb 4, 2014 at 11:08 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> My point is that MediaRecorder is quite a bit more like gUM than it
>> is like RTCPeerConnection and so the same reasoning which kept
>> it in gUM equally well applies to MediaRecorder.
>>
>
> Even if we grant the antecedent, I don't think the implication follows.
>
> So, again, I ask
>> what argument do you have for why constraints are bad for
>> MediaRecorder that don't equally well apply to gUM? [0]
>>
>
> I think the downsides of Constraints are present for gUM as well as
> MediaRecorder, but possibly the use-cases for gUM justify the complexity.
>
> Also, the cost of creating a MediaRecorder you don't want can be made very
> low, which makes certain kinds of capability testing easier. That's less
> true with gUM.
>

I agree that this is true to some extent, but TBH I found it more
convincing before your post above suggesting that capability testing
might consist of empirically verifying that the browser did what it
promised it did. From the perspective of the consumer of the API,
what I want is deterministic behavior and that includes errors when
I ask for something the UA won't.

ISTM that there are two arguments one could offer here:

1. The JS shouldn't get to dictate to the browser, so effectively its
requests in the API are just hints and the browser can silently
not comply and the JS either has to examine the parameters
of the response or (in the limit) actually directly verify the
browser's behavior.

2. The JS should be allowed to dictate to the browser but constraints
aren't a good mechanism for doing that.

I had thought you were arguing #2, but perhaps you are arguing #1?
Or something else I haven't listed.

-Ekr