[whatwg] <device> element, streams and peer-to-peer connections
Anne van Kesteren
annevk at opera.com
Fri May 21 01:29:49 PDT 2010
On Fri, 21 May 2010 10:20:00 +0200, Nicklas Sandgren
<nicklas.sandgren at ericsson.com> wrote:
> As mentioned in the draft, the peer-to-peer API must rely on underlying
> protocols/mechanisms to establish the connections and to transport the
> streams. What are the thoughts regarding these protocols, and has there
> been any discussion around this topic?
Last I checked the hope is that the protocol problem will "go away". So
far it seems that is unlikely. :-)
> An alternative approach could be to define APIs for managing streams
> only, and leave session set up as well as additional functionality
> (file, text, image share) to the application using the means already
> available such as XMLHttpRequest and WebSocket. The session set up would
> in this scenario not rely on a third party server, but rather be handled
> by the server that serves the current web application. This would remove
> the need for agreeing on formats for client and server configuration
> strings or protocols to talk to third-party servers.
>
> You could also debate how often peer-to-peer media streams will actually
> work. Aren't FWs and NATs going to give problems in many cases? Maybe it
> would be better to design for a situation where the media always go via
> a server. Additional benefits are that WS could be used for media
> transport, and that the media could be transcoded if the codec
> capabilities of the clients do not match.
I'm not really sure how this is an alternative approach. It would just be
leaving peer-to-messaging out... Streaming video via WebSocket is
something we definitely want to enable in due course, irrespective of
whether peer-to-peer messaging comes to fruition.
--
Anne van Kesteren
http://annevankesteren.nl/
More information about the whatwg
mailing list