- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 19 Jun 2012 16:13:15 +0200
- 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