- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Sun, 9 Feb 2014 22:45:03 +1300
- To: Eric Rescorla <ekr@rtfm.com>
- 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>
- Message-ID: <CAOp6jLbOr0rBcEW6KxhX9hq+zrErb7q6UW74vgRCL-w80AhiOw@mail.gmail.com>
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. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Received on Sunday, 9 February 2014 09:45:30 UTC