Re: Proposal: Time out for getUserMedia.

On 31/08/2013 1:30 PM, Martin Thomson wrote:
> On 31 August 2013 00:49, Kiran Kumar <g.kiranreddy4u@gmail.com> wrote:
>> I don't mean that application want complete control over this
> Then perhaps you can explain what control you do want more precisely.
> Otherwise, this is looking very much like a Chrome feature request to
> me.
>
> I didn't find Gili's argument particularly interesting, because
> applications can always just immediately close any granted track.
> Also, if we ever decide to actually allow the construction of tracks
> directly, you could close a track to cancel the associated gUM
> request.
>
Hi Martin,

     I must be missing something because I it is my understanding that 
you only get MediaStreamTrack after getUserMedia() returns successfully, 
so how would you "close a track to cancel the associated gUM request"?. 
Here are two use-cases:

Use case #1: Timeout

  * Invoke getUserMedia() to access the local webcam.
  * If 10 seconds elapse and the user still hasn't granted access,
    assume he/she is confused. Cancel the prompt and redirect to some
    help page.
  * If the user really is confused by the prompt (doesn't see it, or
    doesn't understand why we need access to their camera), they are
    more likely than not to close the tab (or navigate away). In such a
    case, waiting for getUserMedia() to return and then discarding the
    track is not really an option.

Use case #2: External stimuli

  * Invoke getUserMedia() to access the local webcam.
  * Before the user can accept, an external entity kicks him/her out of
    the room. Cancel the prompt and redirect back to the "lobby" with an
    explanation.
  * Imagine the case where someone calls you at home (conventional phone
    call), hangs up and tries calling you back immediately (perhaps
    there was some connectivity problem in the initial call).
    Unfortunately they get a "busy" signal because you haven't hung up
    your phone yet (from the first call). Similarly, imagine what
    happens in WebRTC when a remote peer calls the local peer, hangs up
    and then calls back before the local one has answered the prompt. In
    such a case, the remote peer will get a "busy" signal or worse "no
    answer". On the local end, the user accepts the call only to find
    out that he's "one prompt behind" and as a result he's missed both
    calls.
  * I'll give another example you'll appreciate :) Skype: If someone
    calls me and hangs up before I accept the call, the prompt is
    dismissed immediately. That person is then free to call me back
    immediately without getting a busy signal. I think this approach
    makes more sense.

Kind Regards,
Gili