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,

     Thank you for another frank response.

On 23/07/2013 5:22 AM, Stefan Håkansson LK wrote:
> I'm sorry to hear you are frustrated, but I think you will have to be a
> bit patient, and also recognize that this is not a WG starting fresh.
> This WG has an official API document that has been in the making for a
> long time, while I interpret your proposals as something along the lines
> of "let's start fresh, and do I propose to do it this way".

     The existing API has a very small surface area so I was saying that 
refactoring it would entail a much smaller effort than the underlying 
implementation to begin with.

> I think that the most common ground may very well be "let's finalize the
> current work first, and then move on to a new version" or something
> similar, but I am listening to the input on the list (and we should
> probably have a teleconf in August as well to discuss further).

     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.

     This will ensure our continued ability to evolve the API in the future.

> The chairs are listening to the discussion, but please remember that
> there has been long discussions in the past resulting in the current API
> approach. Those discussions took place in public, so I don't think you
> can really say it is forced on us without consensus.
>
> The recent discussions are not unnoticed, but we need to balance this.
> If we never stick to decisions, we will never finalize anything.
>
>>       A few days ago Eric Rescorla wrote: "There have been a large number
>> of posts from a relatively small number of people, but that doesn't make
>> it consensus." I view that as part of the problem.
> Compared to the number of people who have been involved in the last two
> years of discussion leading to the current API document, I think Eric is
> right.
>
> At the same time, we see new input now from people who were not very
> active a year ago, and there is also insights developed by those who
> where active then.

     This approach is very wishy washy. It's not clear who the active 
participants are, so it's hard to prove that a proposal has "consensus" 
at any given time. The practical impact is that it's virtually 
impossible to challenge the Working Group's personal view and this 
becomes much less of a community effort.

     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?

>>       How do we prove consensus on any topic in a way that will elicit an
>> official response from the Chairs? The community needs guidance from the
>> Chairs, otherwise we will continue to argue endlessly and this doesn't
>> serve anyone's interests.
> The chairs are listening to the discussion, and we will most likely call
> for a teleconf sometime in August to discuss further.
>
> But to re-iterate some stuff:
>
> * Proposals, ideas, discussion etc. is never forbidden. That was my main
> message below as there have indications on the list that chair's (and
> other influential persons) have stopped people from speaking.
>
> * The WG has come far with an API (and there are even implementations
> out there, and in use). We're not starting out fresh from square one.
>
> * I think the real question now is not whether there is a desire for an
> alternatively designed API or not, but how to balance that with the
> ongoing work on finalizing the current API. I think this is what we need
> to flesh out.

     I would suggest compiling a list of stakeholders asking for a 
low-level API, scheduling a call with them and the designers of the 
existing API and flesh out concrete action items to ensure that the 
existing API does not unnecessarily compromise the design of a future 
low-level API. One (important) point: do not assume that these 
stakeholders speak with a single voice. There is a general consensus for 
the need of a low-level API, but at this point different people have 
different ideas in mind. We need to gather an all-inclusive list and, as 
much as is reasonable, ensure that the current API does not prevent any 
of their use-cases.

Thank you,
Gili

Received on Tuesday, 23 July 2013 12:00:00 UTC