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

Re: [mediacapture-fromelement] define behaviors of the common ConstrainablePattern Interfaces

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Mon, 13 Feb 2017 19:51:09 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issue_comment.created-279502473-1487015466-sysbot+gh@w3.org>
The Constrainable pattern was designed for device discovery and 
sharing. It's complex, because A) people's devices may not suit your 
needs, and B) devices you get may already be in use, effectively 
shared with another party (another tab) - without any knowledge of 
other parties - which puts a cramp on available settings. It's an API 
designed around compromise and negotiation.

A rescaler is the opposite of that. If you ask for 800x600, you'll 
always get it. Every time. Exactly.

This makes the Constrainable pattern overkill and a terrible API for a
 rescaler.

It's also a weak API, because the pattern allows huge variance in 
browser implementations. Maybe you'll get `OverConstrainedError` if 
you used `exact`, maybe it'll succeed with different values than you 
asked for if you used `ideal`. Instead, you just want all browsers to 
rescale. Every time. Exactly.

> In case any of the common ConstrainablePattern Interfaces is 
irrelevant, the spec should call that out explicitly.

I'd say on the contrary, unless a source explicitly defines 
constrainable properties, then there are none implied by simply 
pulling in a pattern. E.g. None of the properties `width`, `height` or
 `frameRate` come with the ConstrainablePattern.

Also, IMHO we should start with needs, not go looking for 
functionality to implement out of some need for symmetry.

>From the needs I've heard, something straightforward like what 
@pehrsons mentions sounds better to me.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at 
https://github.com/w3c/mediacapture-fromelement/issues/48#issuecomment-279502473
 using your GitHub account
Received on Monday, 13 February 2017 19:51:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:31 UTC