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

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 have a proposal for removing Offer/Answer yet, but this is 
something we can certainly look at.

> If you go back in mail archives and meeting minutes, it is quite easy 
> to find out who has been active. And the base of the current API draft 
> has been published as a FPWD (after a call for consensus), and the WG 
> has since been continuously been developing it (with lots of input 
> given on the mail list as well as in meetings). I think that it 
> represents a community effort. 

     I think part of the problem (which I only became aware of recently) 
is that most of these discussions have been taking place in the rtcweb 
mailing list, not webrtc-public. I wasn't even aware of the existence of 
the first list until recently. Because the API contains SDP and SDP is 
mostly covered by the former list, a lot of discussions that ended up 
affected the API actually took place outside this list (at least 
initially, nowadays a lot of the discussion has moved here).

>>        The Working Group is made up primarily of Browser Vendors and
>> Telecoms. Of the few Web Developers on the Working Group, none seems to
>> be active in discussions. How do you plan on rectifying this problem?
> There is only so much that can be done inside a W3C WG. One thing is to
> make drafts public to get input from a wider audience (that we did).
>
> But apart from that, many WG participants have arranged, or taken part,
> in events specifically targeting developers. There are also books
> authored by individuals active in the WG. I think there are a lot of
> activities to get Web Developer input, but we can always improve. Do you
> have any specific proposals?

     Yes. Perhaps the easiest way to handle this (without affecting the 
1.0 schedule) is to further reduce the scope of the WebRTC API 
exclusively to browser vendors. Meaning, the goal of W3C should be to 
provide a low-level API for browser interoperability. Telecoms and Web 
Developers would then develop their own APIs on top, outside the scope 
of this effort. I think this makes sense for two reasons:

  * We need a standard browser API for the sake of interoperability. W3C
    is all about developing precisely these kinds of APIs.
  * Historically-speaking, Web Developers (and I believe Telecoms too)
    do not have unified higher-level APIs. They can have multiple,
    competing APIs within their respective domains.

     I believe you will find it much easier to find consensus and ship 
WebRTC 1.0 earlier if you take this approach. I also think Telecoms and 
Web Developers will be happier because they can debate with like-minded 
individuals and developing best API(s) for their respective domains.

Gili