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 09:17:43 -0700
Message-ID: <CABcZeBPQ=474J=XwFDhDtKdHVVPEZnQ9b5ZuiWORY4c5b1W5PQ@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Thu, Jul 25, 2013 at 9:02 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  On 25/07/2013 11:30 AM, piranna@gmail.com wrote:
>
>  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).
>
>
>  You have objects whose data will need to be transfer, but instead of
> be required to be done in a SDP blob, the format will be a decision of
> the developer about what best fit for its application, being this SDP,
> JSON, MessagePack or whatever (also custom ones). Also this would lead
> to have an abstract API instead of one SDP oriented.
>
>
>     You can approach this in an incremental fashion:
>
>    1. Start by moving all use-cases off SDP (this is already planned for
>    1.0).
>    2. Hide SDP from the API but continue to use it in the implementation.
>    3. Allow users to handle the conversion from Constraints to the
>    network format.
>
>
This last statement doesn't really work. There's no straight line conversion
from constraints to SDP.

I would suggest that you sit down and try to flesh this out for yourself and
look at what various pieces of the system would have to do. I think when
you make it concrete you'll find that this isn't really workable.

-Ekr
Received on Thursday, 25 July 2013 16:18:51 UTC

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