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