Re: Bare constraint values - KISS

Is {video: {mediaSource: {exact: "application"}}} really that bad for a JS
developer to write?  I appreciate that it's slightly ugly (this coming from
an original fan of "bare == required"), but I don't think it's bad enough
to warrant blowing up or rewinding lots of other things in other places.




On Tue, Jul 8, 2014 at 10:20 PM, Jan-Ivar Bruaroey <jib@mozilla.com> 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.
>
> 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 :.
>
>
>