RE: <device> questions

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.