W3C home > Mailing lists > Public > public-media-capture@w3.org > July 2014

Re: Future of SourceType - Call For Consensus?

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Tue, 08 Jul 2014 01:08:09 -0400
Message-ID: <53BB7CB9.3010101@mozilla.com>
To: Eric Rescorla <ekr@rtfm.com>, Harald Alvestrand <harald@alvestrand.no>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
> On Fri, Jul 4, 2014 at 1:01 AM, Harald Alvestrand 
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>> At the moment, we have 3 bugs that touch on SourceType, listed here:
>> https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=sourcetype&list_id=40270
>> Reminder: SourceType is this enum:
>> enum SourceTypeEnum {
>>     "none",
>>     "camera",
>>     "microphone"
>> };

I think SourceTypeEnum is ill suited for extensions that aren't 
subclasses of cameras or microphones because it has no obvious default 
value, which means old code sees new devices. If we added, say, a 
"screen" value to that enum then screen devices would start showing up 
among cameras (assuming we're doing video constraints) on old browsers. 
The only reason cameras and microphones don't mix is because we 
segregate them explicitly. So to make this work we'd have to add a new 
top-level type next to audio and video for every new SourceTypeEnum and 
explicitly support it at the top level, with it's own set of constraints.

On 7/7/14 6:33 PM, Eric Rescorla wrote:
> On Sun, Jul 6, 2014 at 1:44 PM, Harald Alvestrand 
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>     Can you think of a way to get someone to volunteer to write such a
>     spec?
> https://github.com/fluffy/w3c-screen-share

MediaSourceEnum (from 
) does have an obvious default, given today's systems and being under 
video: "camera".

I actually recommend we add "camera" as a WebIDL default here, like this:

enum MediaSourceEnum {

dictionary MediaTrackConstraintSet {
   ConstrainMediaSource mozMediaSource = "camera";

Because doing so has a desirable effect:

A default value here means all uses to date as well as all uses that 
don't explicitly provide a different value will get mediaSource: 
"camera" implicitly, which will filter out all screensharing devices by 
default, which I think is what we want. We don't want screensharing 
devices to pop up in the regular camera list.

There'll effectively be "sub-pools" of devices (cameras, browsers, 
application and screen) that users will never see a union of, which I 
believe we desire.

.: Jan-Ivar :.
Received on Tuesday, 8 July 2014 05:08:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:28 UTC