- 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
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