RE: <device> questions

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] 
Sent: Wednesday, December 15, 2010 1:36 AM
To: Young, Milan
Cc: 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>
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] 
Sent: Tuesday, December 14, 2010 2:16 PM
To: Young, Milan
Cc: 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.