- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Wed, 11 Sep 2013 16:54:23 -0400
- To: public-media-capture@w3.org
- Message-ID: <5230D87F.7030703@bbs.darktech.org>
Kiran, I believe you misunderstood my point. The use-case I brought up (cancelling getUserMedia() due to a server event) cannot be solved using the timers you mentioned because there is no way of knowing in advance how long to wait. On the contrary, with my proposal you can cancel() from within setTimeout() to implement your use-case. Gili On 11/09/2013 5:09 AM, bugzilla@jessica.w3.org wrote: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=23194 > > Kiran <g.kiranreddy4u@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > > CC| > |g.kiranreddy4u@gmail.com > > --- Comment #2 from Kiran <g.kiranreddy4u@gmail.com> --- > The time out I proposed here, will comprise of both the cases. > 1. A default timer will be started after calling getUserMedia(). > 2. A facility will be provided to the user to set his own timers (with > some > conditions for example very low or unacceptable values will be > discarded). > > > (In reply to Gili from comment #1) >> I'd like to propose a variation of this proposal. >> >> Instead of specifying a timeout, developers should be able to cancel a >> getUserMedia() call at any arbitrary time. >> >> If we implement a mechanism similar to setInterval(), clearInterval() >> then >> users will be able to cancel after a timeout (as Kiran suggested) as >> well as >> due to external (server-driven) events. This has UX benefits. >> >> Use-case: A user enters a video conferencing bridge. Before she grants >> permission to the camera, the call ends and all users are ejected >> from the >> room. >> >> Instead of asking users to respond to a stale prompt, the server can >> abort >> the operation and notify the user that the call has ended.
Received on Wednesday, 11 September 2013 20:55:15 UTC