W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2013

RE: Fwd: Proposal for some constrains we need

From: Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net>
Date: Thu, 31 Jan 2013 21:19:24 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A484161C358F@tk5ex14mbxc272.redmond.corp.microsoft.com>
From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, January 31, 2013 6:22 AM
To: public-webrtc@w3.org
Subject: Re: Fwd: Proposal for some constrains we need

On 01/31/2013 08:21 AM, Justin Uberti wrote:
This feels like we are heading down the path of creating a low-level API, but using constraints, which seems like the wrong control surface.

Wouldn't it be better to provide accessors on SessionDescription to allow these properties to be set directly? This would allow any configuration to be set without having to a) add a constraint for each feature and b) perform any SDP munging.


My thinking for some of these is that they're backwards compatibility hacks that are only needed when talking to legacy devices where standard SDP negotiation won't do the Right Thing.

I totally disagree here. I think you’re seriously underestimating what clever web developers would do if they had an API surface to work with (other than trying to mangle SDP in JavaScript and hope that the undocumented set of SDP that is accepted matches their changes).

Assuming that “standard SDP negotiation” without manipulation or constraints will “do the Right Thing” is essentially telling those developers that you know better than they do: what codecs would be preferred, how to set parameters on those codecs, how to prioritize audio vs. video, details of data channel setup, when putting audio and video on the same port is a good idea, etc., etc., etc.

The history of all interesting and innovative apps within browsers is filled with “wow, we let the developer control <X> and we had no idea that a clever developer would be able to do <Y> as a result!”

That’s why Google Maps implemented on top of some JavaScript APIs and existing abilities to display and manipulate images was *more* interesting than building a “map control” into every browser.

And why putting a SIP phone into a browser isn’t nearly as interesting as exposing the ability to set up compressed realtime audio and video streams between a pair of browsers and/or a browser and a server.

Matthew Kaufman
Received on Thursday, 31 January 2013 21:20:12 UTC

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