Re: Proposal: Time out for getUserMedia.

Hi,

     What do you mean by "the object that gUM is attempting to connect 
to the source"? Perhaps it'll be easier to understand if you provide 
some pseudo-code showing how you see this working.

Thanks,
Gili

On 01/09/2013 2:09 PM, Martin Thomson wrote:
> 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:37:29 UTC