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

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

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 21 May 2010 10:29:49 +0200
Message-ID: <op.vc1q7jxd64w2qv@annevk-t60>
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/
Received on Friday, 21 May 2010 01:29:49 UTC

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