<div class="gmail_quote">Has anyone spent any time imagining what a microphone/video-camera API that supports the video conference use case might look like?  If so, it&#39;d be great to see a link.</div><div class="gmail_quote">

<br></div><div class="gmail_quote">My guess is that it&#39;s going to be much more complicated and much more invasive security wise.  Looking at Bjorn&#39;s proposal, it seems as though it fairly elegantly supports the use cases while avoiding the need for explicit permission requests (i.e. infobars, modal dialogs, etc) since permission is implicitly granted every time it&#39;s used and permission is revoked when, for example, the window loses focus.</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">I&#39;d be very excited if a WG took a serious look at microphone/video-camera/etc, but I suspect that speech to text is enough of a special case (in terms of how it&#39;s often implemented in hardware and in terms of security) that it won&#39;t be possible to fold into a more general microphone/video-camera/etc API without losing ease of use, which is pretty central the use cases listed in Bjorn&#39;s doc.</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">J</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, May 19, 2010 at 9:30 AM, Anne van Kesteren <span dir="ltr">&lt;<a href="mailto:annevk@opera.com">annevk@opera.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">On Wed, 19 May 2010 10:22:54 +0200, Satish Sampath &lt;<a href="mailto:satish@google.com" target="_blank">satish@google.com</a>&gt; wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don&#39;t really see how the problem is the same as with synchronous<br>
XMLHttpRequest. When you do a synchronous request nothing happens to the<br>
event loop so an alert() dialog could never happen. I think you want<br>
recording to continue though. Having a simple dialog stop video conferencing<br>
for instance would be annoying. It&#39;s only script execution that needs to be paused. I&#39;m also not sure if I&#39;d really want recording to stop while looking at a page in a different tab. Again, if I&#39;m in a conference call I&#39;m almost always doing tasks on the side. E.g. looking up past discussions, scrolling through a document we&#39;re discussing, etc.<br>


</blockquote>
<br>
Can you clarify how the speech input element (as described in the current<br>
API sketch) is related to video conferencing or a conference call, since it doesn&#39;t really stream audio to any place other than potentially a speech<br>
recognition server and feeds the result back to the element?<br>
</blockquote>
<br></div></div>
Well, as indicated in the other thread I&#39;m not sure whether this is the best way to do it. Usually we start with a lower-level API (i.e. microphone input) and build up from there. But maybe I&#39;m wrong and speech input is a case that needs to be considered separately. It would still not be like synchronous XMLHttpRequest though.<div>

<div></div><div class="h5"><br>
<br>
<br>
-- <br>
Anne van Kesteren<br>
<a href="http://annevankesteren.nl/" target="_blank">http://annevankesteren.nl/</a><br>
</div></div></blockquote></div><br>