W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2010

[whatwg] <device> element, streams and peer-to-peer connections

From: Nicklas Sandgren <nicklas.sandgren@ericsson.com>
Date: Fri, 21 May 2010 10:20:00 +0200
Message-ID: <0F407DE9946A304F81F5C37C1DB6002A3C0D10EE@ESESSCMS0359.eemea.ericsson.se>
Looking at the latest draft, section 4.11.6 contains a proposal for the <device> element as discussed quite extensively on the W3C DAP list. In addition there is a Stream API and a sub-section on peer-to-peer connections.

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?

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.

--Nicklas Sandgren


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100521/54428374/attachment.htm>
Received on Friday, 21 May 2010 01:20:00 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:23 UTC