Re: Bare constraint values - KISS

On 7/9/14 2:32 PM, Martin Thomson wrote:
> I think that screwing with constraints further (ekr: feel free to say
> "I told you so" now) isn't what we are looking for.  Rather than
> contorting to accommodate every new feature, we should take a step
> back and look at what the requirements are.

Since I'm effectively arguing to take one small step *back* because of 
semantic overcomplexity, I consider it unscrewing. The ideal/exact 
inversion I think better fits the description of a contortion, given 
that we purposely accepted a cost for some perceived gain.

> 1.
>
> I know that a call pattern like:
>
> ...getUserMedia({audio: false, video: false, application: true}, ...)
>
> ... might be uncomfortable or inconvenient for us to implement in
> Firefox, but I think that it's actually how people think of this.  And
> we already need to fix our code.  We can talk about having an
> allowance for failure when the sources are disparate if you like.

I agree with this.

> Another reason that I'm starting to like this is that the basic set of
> constraints we apply for camera sources are very different to those
> that apply elsewhere.

width? height? frameRate? Our constraints are effectively in one pool 
already, so I don't think this matters on way or the other.

> Since the depth (or range) input folks are already headed in this
> direction, I think that this makes even more sense.  This makes the
> "audio" and "video" labels a little less good, but I think that we can
> probably live with that.

I agree the labels would now stink. I don't know enough about the 
original reasons for picking the audio/video division. 
Screensharing-as-a-video is not a new form of "media" the way 
"smellovision" would be. Though cramming a screenshare into a video 
format is perhaps not the ideal screenshare format either (if I compare 
to, say, vnc or remote desktop formats).

> 2.
>
> Tim T pointed out a consideration that might be relevant: screen
> sharing can also include audio - and some applications actually
> support that - but I think that we probably want to be a little
> cautious about adding that.  Though that would favour a form that
> globally switches mode, rather than something local to a video
> constraints:
>
> ...getUserMedia({audio: false, video: true, source:
> "application|livecapture"}, ...)
>
>
> My preference tends slightly toward the second option.

Good point. If we stick to the audio/video division, then we'd logically 
have to add a new "soundsharing" audio type to accomplish this.

Sounds like we need a refresher on what the top division is supposed to 
serve.

.: Jan-Ivar :.

Received on Thursday, 10 July 2014 12:37:23 UTC