Re: Responsive constraints (was: Re: Mandatory vs optional constraints)

On 08/27/2012 02:47 PM, Rich Tibbett wrote:
> Harald Alvestrand wrote:
>> Changing the subject line, since this has absolutely nothing to do with
>> the syntax or semantics of the resolution constraints....
>
> I believe this is a discussion on the merits of either having a 
> responsive approach to constraint management vs. specifying up-front 
> constraints at web application start-up.
>
> That really boils down to a question of user experience when using 
> getUserMedia and is not a decision between mandatory vs optional 
> constraints. Both are still supported either way.
That's what I don't understand in this discussion.

Given that we both agree that it's better for the user if the developer 
writes responsive applications, and given that we both agree that the 
application writer can write both responsive and non-responsive 
applications whether getUserMedia supports mandatory constraints or not, 
what is it in this discussion that matters to whether a browser should 
support mandatory constraints in getUserMedia?

A word like "incentivizing the app developer" doesn't parse for me.

> Agreed. But giving developers up-front constraints as an 'easy-out' to 
> avoid responsibility for providing responsive service to as many users 
> as possible in a heterogeneous web environment is going to fragment 
> and damage the long term health of the web.
>
> Making the browser responsible for rejection of service up-front is 
> also a convenient way to defer developer responsibility here. That 
> would be bad. 

That part totally doesn't parse for me. All the difference I see is that 
the developer has to put code into the error handler instead of in the 
success handler; the developer is still 100% responsible in all cases, 
there is no automatic UI of rejection.

Out of sequence quote:

>> What I'd like to therefore see instead is something similar to the
>> following:
>>
>> getUserMedia({ video: true }
>> }, successCallback, errorCallback);
>>
>> function successCallback(stream) {
>> // attempt to scale up to HD resolution (if it is supported
>> // on this device)
>> stream.videoTracks[0].width = 1024;
>> stream.videoTracks[0].height = 768;
> This is, of course, totally user-hostile.
>
> If the user has just bought a 4k camera, and his browser, his computer
> and his network all support that, he has a reasonable expectation that
> he should just plug it in in place of his old camera, and it should Just
> Work - because the app has (correctly) told the browser that there are
> *minimum* requirements, but no *maximum* requirements.
>
> Your code example, if approached in this fashion, is actively hurting
> the future-proofing of the Web.
(quote from Rich commenting on the above below, copy/paste didn't quite 
work right)
>
> You may have to explain this statement as I don't quite follow.
>
> In your example, the old camera was flat out rejected up-front without 
> much ado. In the responsive approach the old camera worked, albeit at 
> a lower resolution, because the developer was incentivized to make it 
> work to improve the user experience of their web application (because 
> otherwise the user just got a 'Can't do' message). The new camera just 
> happened to provide higher resolution than the old camera but still 
> worked in the same way.
This is not an argument about constraints, it is an argument against the 
particular API you seem to be suggesting as an alternative.

What your code does (and I think it's a very likely scenario that many 
people will write their code this way, if constraints aren't easily 
available) is that it *clamps* the resolution to 1024x768, as long as 
the camera supports it at all. In the first year of that code's 
deployment, it will effectively mean "1024x768 or lower", because 
1024x768 is a "high end camera", and better cameras are very rare.

Most cameras that support better resolution than 1024x768 are also 
capable of supporting 1024x768. So three years later, the meaning is 
"1024x768, and no higher".

Building in obsolescence in this way is not good for the user.