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).

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

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