- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 15 Dec 2010 10:09:42 -0800
- To: Satish Sampath <satish@google.com>
- CC: "Young, Milan" <Milan.Young@nuance.com>, public-xg-htmlspeech@w3.org
On 12/15/2010 09:59 AM, Satish Sampath wrote: > Hi Milan, > > The Device API is not part of the Device Access and Policy WG (DAP WG). > Please join the WHAT WG which handles the Device API as part of the > HTML5 spec. And AFAIK neither Mozilla nor Google is anymore in DAP WG. -Olli > > Cheers > Satish > > > On Wed, Dec 15, 2010 at 5:52 PM, Young, Milan <Milan.Young@nuance.com > <mailto:Milan.Young@nuance.com>> wrote: > > I just joined the Audio and Device working groups. Will start > participating at the start of the year. > > But I still think it may be appropriate to request an invited > expert. I remember doing this in the VBWG when we were considering > DOM integration with VoiceXML events. It was effective in getting > us quickly up to speed. > > Maybe something for the <chair>s to consider. > > ------------------------------------------------------------------------ > > *From:*Satish Sampath [mailto:satish@google.com > <mailto:satish@google.com>] > *Sent:* Wednesday, December 15, 2010 1:36 AM > > > *To:* Young, Milan > *Cc:* public-xg-htmlspeech@w3.org <mailto:public-xg-htmlspeech@w3.org> > *Subject:* Re: <device> questions > > Yes there is a risk, though there is sufficient interest in a Device > API that it will be picked up soon (I think Ericsson Labs even have > a prototype implementation out now). > > > Any thoughts about inviting IETF and/or Connection Peer experts to > our calls? > > I'm not very sure, but if we want to contribute to the Device API > spec perhaps some of us should participate in their group/call > rather than inviting them to ours? > > > Cheers > Satish > > On Wed, Dec 15, 2010 at 2:24 AM, Young, Milan > <Milan.Young@nuance.com <mailto:Milan.Young@nuance.com>> wrote: > > Thanks Satish. Great information. > > The line between requirements and implementation is starting to > blur. Perhaps it would be worth our while to investigate the > <device> approach in parallel with requirements. > > The approach carries risk, because we might find <device> to be a > dead end. But then at least we would know it’s a dead end and it > would better frame the protocol and privacy discussions. At present > it’s difficult because the potential implementation paths are so > diverse. > > Any thoughts about inviting IETF and/or Connection Peer experts to > our calls? > > ------------------------------------------------------------------------ > > *From:*Satish Sampath [mailto:satish@google.com > <mailto:satish@google.com>] > *Sent:* Tuesday, December 14, 2010 2:16 PM > *To:* Young, Milan > *Cc:* public-xg-htmlspeech@w3.org <mailto:public-xg-htmlspeech@w3.org> > *Subject:* Re: <device> questions > > Hi Milan, > > > * How does the connection peer proposal tie in with streaming > speech audio? I see support for addStream(), but this whole API > seems to be oriented around peers rather than client/server. Is > this just a pattern to follow, or would we try to re-use verbatim? > > Yes ConnectionPeer is currently geared towards peers and I was > hoping we from this XG can influence to add client-to-server > functionality as well. > > * Any thoughts on using WebSockets to transmit the data? > Lower overhead might make it a better choice for streaming > compared to chunking. Bidirectional communication would enable > additional use cases and would probably simplify the process of > canceling a request. > > WebSockets are good if the data being sent and received is > text/strings and is available to the web application. Were you > thinking about the web app's script getting raw audio and sending > through a websocket, or just connecting a stream from the <device> > tag to a websocket? The latter seems close to the ConnectionPeer > model and we may have to get in touch with the WebSockets group in > IETF to discuss. > > * Is anyone aware of standards work exposing the microphone > via <device>, or would this be virgin territory? Privacy is an > area where we will have a lot of requirements. > > As of now we just have a generic "media" which is suitable for > audio+video capture devices. I think we can bring it up in the > WHATWG mailing list with our use cases. Privacy should already be an > issue which <device> will be addressing and we could piggy back on that. > >
Received on Wednesday, 15 December 2010 18:10:25 UTC