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

Re: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 25 Jul 2013 08:24:23 -0700
Message-ID: <CABcZeBPz5eBGv4_pWuBOQut7Vgd7-pSQKOfD4eCm2JDOAihMGw@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>, Peter Thatcher <pthatcher@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Thu, Jul 25, 2013 at 6:53 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  HI Stefan,
> On 24/07/2013 4:43 AM, Stefan Håkansson LK wrote:
>        As I mentioned in reply to Justin's post, I would suggest that you
> take the time to ensure that the API you are publishing does not force
> inappropriate design constraints on the low-level API that will follow.
> Off the top of my head, I'm guessing that you can layer SDP on top of an
> API without it, but the same does not hold true for Offer/Answer.
> Hopefully someone can suggest minor changes to remove these constraints
> and still allow you to achieve the same goals.
>  I think there has been other input in the same direction. But this is
> also a balancing act, this could bog down the progress towards 1.0.
> There are no easy answers here.
> The following proposal would allow us to remove SDP without bogging down
> progress towards 1.0:
>    1. Move all major use-cases from SDP to the Constraints API (as we're
>    already doing)
>    2. Expose experimental Constraints behind a flag, instead of using SDP
>    (this is consistent with what browsers already do)
>     3. Remove SDP from the WebRTC API. Layer a separate (out of scope)
>    API on top of WebRTC that would translate from/to Constraints to SDP.
I don't see how this would produce a useful artifact. What would the browser
emit to be inserted in signaling messages? It has to be something (at least
in the current model).

Received on Thursday, 25 July 2013 15:25:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:50 UTC