Re: Constraints and MediaRecorder

On Sun, Feb 9, 2014 at 1:45 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Sun, Feb 9, 2014 at 9:28 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> On Mon, Feb 3, 2014 at 4:04 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>>
>>> On Tue, Feb 4, 2014 at 12:25 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> OK, but the Web likes graceful degradation when feasible. That's why we
>>> don't throw errors when you use an unsupported CSS property in a
>>> stylesheet, and why 2D canvas silently skips rendering operations when
>>> given NaN parameters. This is partly because the Web has a cohort of
>>> mediocre developers and poorly maintained apps, partly because the Web has
>>> heterogenous implementations with different levels of API support, and
>>> partly because Web implementations compete on how many apps they can run so
>>> economics favour permissiveness. (There are yet other reasons applying to
>>> specific examples.) Having said that, I appreciate that degree of
>>> permissiveness involves tradeoffs that have to be analyzed on a case by
>>> case basis.
>>>
>>> In this case we have some consumers who want to provide optional
>>> constraints, and others who want to provide mandatory constraints, and
>>> providing a single API that provides both without confusing anyone over its
>>> semantics is a bit hard. If we go with only optional constraints, and let
>>> people implement mandatory checking via inspection APIs that we'll probably
>>> have to provide anyway, it feels like a win to me.
>>>
>>
>> I'm still finding myself confused about what you mean by "inspection APIs"
>>
>> Say, for instance, that I want the MediaRecorder to record at 192 kHz.
>>
> So we have some mechanism for me to ask for that and then the browser
>> gives me back a MediaRecorder with some properties it thinks are
>> appropriate. Are you arguing that there should be some API that will
>> allow me to interrogate the object and see what I got (which would
>> have to exist for every constraint, presumably) or that I have to
>> directly test the object for its properties, e.g., by passing in audio
>> and then seeing if it retains the high frequencies?
>>
>
> The former --- assuming there's a use-case where you really need to know,
> at the time of recording, whether those frequencies are being recorded.
>

I'm surprised to hear you put it this way. You mean that there might be
some value you could indicate in the API but that you can't determine
if you got because the WG had decided you didn't have a good enough
use case for that? Why is that a good idea?

-Ekr