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 Gili,

some more comments in-line below.

On 7/23/13 1:59 PM, cowwoc wrote:
> 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.

OK. Reading my own input above I realize it could be read it as that I 
imply that you are proposing a certain API design. That is not what I 
meant, you have been proposing ways we should work (which I appreciate), 
but those seem to assume we're starting out fresh (which we aren't).

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

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.

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

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.

>
>       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?

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

This sort of underlines what I have been saying. Agreeing on a need for 
a lower level API is not the same as agreeing on its design, and 
agreeing on that could take some time. That is why I think it is a good 
idea to get a 1.0 version based on what we have now out of the door - 
there would be something stable available to developers.

Your proposal on how we go about working towards a lower level API is 
appreciated.

>
> Thank you,
> Gili
>

Received on Wednesday, 24 July 2013 08:44:17 UTC