Re: Bare constraint values - KISS

On 09/07/14 07:21, Jan-Ivar Bruaroey wrote:
> I ran into some constraint-stuff while we attempted to implement
> screen-sharing.
>
> http://htmlpreview.github.io/?https://raw.githubusercontent.com/fluffy/w3c-screen-share/master/screenshare.html#screen-based-video-constraints
>
>  In this particular proposal, screen-sharing is a type of video
> source, selected using a mediaSource video-constraint:
>
> enum MediaSourceEnum { "camera", "browser", "application", "screen"
> }; typedef (MediaSourceEnum or sequence<MediaSourceEnum>)
> ConstrainMediaSource;
>
> dictionary MediaTrackConstraintSet { ...
> ConstrainMediaSourcemediaSource = "camera"; };
>
> Note that the mediaSource constraint has a default value = "camera".
> This is novel, and I just added it.
>
> The reason for it is we don't want screensharing sources and cameras
> to appear in the same list, so if no mediaSource is specified, only
> cameras should be returned (like today). With WebIDL bindings,
> default values appear implicitly in blank dictionaries, so this "just
> works" which is nice.
>
> But here's the rub.
>
> At the interim, we decided that plain constraint values should be
> optional, not required, which means the "camera" default fails to
> produce "just cameras", and we get a mix of screensharing sources
> and cameras returned.
>
> This is a red flag to me on syntax. Having defaults be used in this
> way to segregate mutually exclusive sets seems useful and nicely
> orthogonal to everything else.

To help me understand: this problem surfaced due to the proposed way to 
specify screen/app sharing?

Could an alternative be to change that instead?

(I'm not really opposed to your proposal. I have a small problem with 
the fact that if the app does not check - which it should - if a certain 
constraint is understood by the UA or not it would mean that up to the 
day the UA implements it it would be ignored, but the day it is 
understood it would be required. That is a footgun to me. But my main 
concern is that leaving the consensus of the Interim meeting - even if 
in small steps - could leave us with no consensus at all.)

>
> I'm making a plea to take one small step back from the interim
> consensus and make plain values required by default (and get rid of
> exact).
>
> If you agree, you can stop reading. If not, read on.
>
> ---
>
> We sort of hand-waved and said that it was natural for the following
> to mean optional rather than required:
>
> ...getUserMedia({ video: { width: 640 } }, cb, cb); ...getUserMedia({
> video: { height 480 } }, cb, cb);
>
>
> because asking for exact values when a range of values are available
> was deemed overly restrictive and less useful, hence this semantic
> could be lifted for a more useful purpose. I think we arrived at this
> without considering cases where this is less obvious, like:
>
> ...getUserMedia({ video: { aspect: 16/9 } }, cb, cb);
> ...getUserMedia({ video: { facingMode: "user" } }, cb, cb);
>
>
> These don't seem overly restrictive at all, so why should they NOT
> be required? Semantically, one would assume they were, all else
> being equal. Being able to deduce behavior from semantics seems more
> important than a syntax that tries to guess what you want. Keep it
> simple stupid.
>
> Mandatory isn't a terrible default anymore since we fixed the false
> negatives. I think we should say that bare values are required. Then
> segregation using defaults works, things are silly-simple, and
> people can describe things as narrowly or as widely as they wish,
> using min/max, multi-element sequences and/or ideal (and there is no
> exact). It's simpler.
>
> The first 'optional' example above would then need to be written this
> way:
>
> ...getUserMedia({ video: { width: { ideal: 640 } } }, cb, cb);
> ...getUserMedia({ video: { height { ideal: 480 } } }, cb, cb);
>
>
> which is not a huge inconvenience. Simple first, useful a close
> second.
>
> .: Jan-Ivar :.
>
>
>

Received on Wednesday, 9 July 2014 11:23:04 UTC