Re: Proposal: Time out for getUserMedia.

Hi Martin,

Sorry for the delayed response.

"It leaves the user with a redundant question" will not happen because,
whenever the application receives a negative/failure response, based on the
error code, it will display a page to the user explaining about the
prompt/timeout or other reason.
Actually this solves the problem instead of leaving user
in redundant questions.

for your previous reply, "that application can close the tracks", AFAIK
that is possible only when getUserMedia returns a success response. But we
are discussion about the failure cases.

Coming to " closing of the object that gUM() is attempting to connect to
the source"? (If my understanding is correct)I understand it like, closing
the object which may be either calling the getUserMedia() or going to
receive the callback. Both are not acceptable by application developers,
because it demands a separate object for handling getUserMedia() (which is
not up to the specifications).

I prefer a direct method for handling this kind of failures with a high
level API (I don't mind whether it is through existing callbacks or new
cancellation API or both), Instead of handling it through and indirect
means.

Thanks,
Kiran.


On Mon, Sep 2, 2013 at 12:06 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

> 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
>>>
>>
>
>