On Fri, 21 May 2010 10:20:00 +0200, Nicklas Sandgren
<nicklas.sandg...@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/
