Re: Future of SourceType - Call For Consensus?

On 8/20/14 11:08 AM, Jim Barnett wrote:
> However since MediaSourceEnum applies only to video, perhaps it should 
> be called VideoSourceEnum.  That makes it clearer that it we want to 
> select among different types of audio sources in the future, we will 
> define  AudioSourceEnum.

Sure, but before we get too excited about the mediaSource constraint, 
recall that it has to violate the constraints-model to work.

The documentation for MediaSourceEnum [1] says:
> "camera"     The source is a camera. This is the default.

A default prevents getUserMedia({ video: true }, ...) from suddenly 
returning users' screens which wouldn't be popular.

But default constraints isn't well-defined, except to the extent that 
WebIDL allows default dictionary members: bare values only, and code 
behind bindings cannot distinguish a default member from a real one.

So we tried this, and we ended up cheating to make it work:

 1. Because bare values now mean ideal, defaults wont exclude the other
    types as desired, so we had to special-case mediaSource and treat it
    as "always required".

 2. Advanced no longer worked right, because the implicit "camera"
    default made every advanced-entry conflict with a required
    non-camera mediaSource at the top, so we ended up having to pave the
    defaults with the top-level value.

sourceType would presumably have had the same problems, so good riddance.

We can either work on fixing this, or give up on expanding the video 
(really camera) and audio (really microphone) domains.

.: Jan-Ivar :.

[1] 
http://htmlpreview.github.io/?https://raw.githubusercontent.com/fluffy/w3c-screen-share/master/screenshare.html