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.
>
>
>