Bare constraint values - KISS

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

Received on Wednesday, 9 July 2014 05:21:10 UTC