Re: Bare constraint values - KISS

On 07/09/2014 07:20 AM, 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.

I actually think I disagree. It's not nice. And we don't have a group 
decision saying it's nice.

Reason is: The application has given no hint of what he wants. Making 
the arbitrary decision that for video, we will, now *and forever*, in 
*all possible cases* where the app doesn't say what it wants, return 
cameras only, is a very big decision.

Making that decision isn't something we should do just because it looks 
nice for *this specific case*.

We can either conclude that there will never be a category that 
applications want to see when they just ask for "something that produces 
video" together with the cameras (in which case your suggestion is 
reasonable), or we can conclude that if an application doesn't ask for 
anything specific, any kind of source is fair game.

But I don't see this as having an obvious answer.

Received on Tuesday, 15 July 2014 10:11:31 UTC