W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

Re: [ACTION-43] (sdp related objects and global namespace) - way forward

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 19 Jun 2012 16:13:15 +0200
Message-ID: <4FE088FB.3070608@ericsson.com>
To: Justin Uberti <juberti@google.com>
CC: Dominique Hazael-Massieux <dom@w3.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 06/19/2012 03:42 PM, Justin Uberti wrote:
>
>
> On Tue, Jun 19, 2012 at 4:03 AM, Dominique Hazael-Massieux <dom@w3.org
> <mailto:dom@w3.org>> wrote:
>
>     Le vendredi 15 juin 2012 à 12:07 -0400, Justin Uberti a écrit :
>
>      > I still don't understand why think that developers who are unwilling
>      > to understand these concepts or use a library that takes care of them
>      > will be able to deploy a TURN server or handle the other necessary
>      > aspects of running a reliable communications service.
>
>     I think assuming that PeerConnection will only be used by developers
>     that want to run a reliable communication service is a mistake; as I
>     have said before, the availability of a P2P data channel is likely to be
>     as big if not much bigger in usage than video/audio chat.
>
>
> I agree regarding the potential for the data channel, but said channel
> requires the same infrastructure (i.e. TURN) as voice/video.

In an experimental phase STUN could be sufficient, and then there seem 
to exist publicly available servers (source 
http://www.voip-info.org/wiki/view/STUN). Of course TURN (with some 
fallback - http?) would have to be deployed before being able to launch 
something that is reliable in uncontrolled network topologies.

>
>
>     Leaving the work to libraries has issues of its own (e.g. we'll make Web
>     pages that much slower to load; clearly having every API out there rely
>     on library doesn't scale), and seems to be a sign of giving higher
>     priority to our difficulties over the ones of the developers (see [1]
>     Priority of Constituencies).
>      >
>      > We have spent countless time trying to come up with a perfect API. We
>      > are now at the point where doing so is now holding back
>     developers who
>      > want to build real applications, who simply want a stable API that
>      > supports the functionality they need. We need to polish any remaining
>      > rough edges on the current API and ship it.
>      >
>     The number of developers we are annoying now is very small compared to
>     the number of developers we will annoy in the future if we come up with
>     a poorly designed API, IMO.
>
>
>      > On this topic of the global namespace, other Web APIs (e.g. WebGL)
>      > dump far more names into the global namespace. I don't think that 2
>      > additional names is worth spending a lot of time debating. Either
>      > prefix them, or leave them as-is.
>
>     I don't think WebGL is an example of a particularly Web-designed API —
>     it has been designed for compatibility with OpenGL, something that we
>     don't have in our case.
>
>
>     Dom
>
>     1.
>     http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
>
>
>
Received on Tuesday, 19 June 2012 14:13:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC