W3C home > Mailing lists > Public > public-media-capture@w3.org > February 2014

Re: Constraints and MediaRecorder

From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 8 Feb 2014 12:28:17 -0800
Message-ID: <CABcZeBNk5cv-i+_bEQYqKHRpbrdYWm2z8hbBRQJ7p+q05fUpWg@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Jan-Ivar Bruaroey <jib@mozilla.com>, Harald Alvestrand <harald@alvestrand.no>, Martin Thomson <martin.thomson@gmail.com>, Cullen Jennings <fluffy@iii.ca>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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?

-Ekr
Received on Saturday, 8 February 2014 20:29:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:24 UTC