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

> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org 
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Anne 
> van Kesteren
> Sent: den 21 maj 2010 10:30
> To: whatwg at whatwg.org; Nicklas Sandgren
> Subject: Re: [whatwg] <device> element, streams and 
> peer-to-peer connections
> 
> 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.

What I meant was that if you just specify a lower level API used only 
for sending and receiving media streams, some of the that protocol 
problem would "go away". 

As I see it the only functionality in the Peer-to-peer API that it is
not currently possible to implement using other means (won't be p2p 
but the end result will more or less be the same) is the media stream 
part. Hence, in my opinion, that would be the most interesting feature
to enable.

--Nicklas

Received on Friday, 28 May 2010 01:02:52 UTC