Re: Proposal: Time out for getUserMedia.

Both of those cases can be addressed by ignoring the result, at least initially.

It leaves the user with a redundant question, and that sucks.  I get that.

I do tend to think that cancellation is the right way to deal with
this.  I was suggesting that cancellation could be achieved by closing
the object that gUM is attempting to connect to the source.

On 31 August 2013 22:33, cowwoc <cowwoc@bbs.darktech.org> wrote:
> 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

Received on Sunday, 1 September 2013 18:09:56 UTC