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

Also be aware that some of us who participated in the earlier discussions, and who like the current direction, have been quiet during the current flame wars. When it's time to vote I support the current direction, and I'm not interested in arguing about it. I think that the chairs have been doing an excellent job in a difficult situation. 
Jim 

On Jul 23, 2013, at 5:24 AM, "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com> wrote:

> Hi Gili,
> 
> in-line (and note that my co-chair is having vacation so this represents 
> my views and not the joint view of the chairs):
> 
> On 7/22/13 6:47 PM, cowwoc wrote:
>> Hi Stefan,
>> 
>>     To be honest, I am very frustrated. I have been trying very hard to
>> find common ground with people on this list but it seems that there is
>> too much bad blood (on the list in general) for us to find common ground.
> 
> 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".
> 
> 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).
> 
> 
>> 
>>     Everyone is out to get their way which results in flame-wars
>> breaking out on the mailing list. I think people need to internalize
>> that they will not get their way 100%. It's no coincidence that
>> http://lcsd05.cs.tamu.edu/slides/keynote.pdf slide 11 says "Aim to
>> displease everyone equally" and not the other way around :)
> 
> I have also noted the flame-wars on the list, and personally I don't 
> think it is very constructive.
> 
>> 
>>     I wish people would post something like this:
>> 
>>     "I proposed <brief description> (see <link> for more detail). But
>> in all honesty, it doesn't matter that much. I just want an API that:
>> 
>>  * Abstracts away the network so: (high-level goal, "what" not "how")
>>      o Applications don't need to keep reimplementing protocol-parsers.
>>      o Applications don't break when the network protocol changes.
>>  * I don't mind whether the high-level API is developed by W3C or the
>>    general public. I just want it to be well-designed and easy to use."
>>    (non-goal)
>> 
>>     Non-goals are just as important as goals. People need to state what
>> they are willing to give up in return for what they're asking for.
>> 
>>     Final point: I think there is a lot of distrust between the
>> community and the Working Group. I encourage the Chairs to add
>> transparency by stating their intentions for 1.0.
>> 
>>     I for one am afraid that an API will be forced on us without consensus.
> 
> 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.
> 
>> 
>>     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.
> 
> Best regards,
> Stefan
> 
>> 
>> Thank you,
>> Gili
>> 
>> On 22/07/2013 4:17 AM, Stefan Håkansson LK wrote:
>>> On 7/19/13 11:33 PM, Matthew Kaufman (SKYPE) wrote:
>>>> I sure hope that Peter and folks with similar sentiment don’t
>>>> **actually** think that the WG is requiring them to “wait until 2.0” to
>>>> have these issues addressed.
>>>> 
>>>> Among other things, if the first version can’t be implemented, it won’t
>>>> be a standard… so it would be a shame to have not started on the correct
>>>> API.
>>>> 
>>>> I suppose if the WG chairs are really this inflexible to the membership
>>>> of the WG, we can always start a new WG and get new chairs for it.
>>> (This mail is not addressed to Matthew really, it is more for the entire
>>> list - and it is my personal reflection)
>>> 
>>>  From my perspective, we have been working towards one target for a long
>>> time (and as mentioned we had a poll last year that confirmed that), and
>>> it has not been that controversial. Sure, not everyone likes everything
>>> about the API - I'm pretty sure that no-one likes every aspect of it (I
>>> for one have some issues) - but that is what you often get out of a
>>> community effort.
>>> 
>>> There are also implementations of the to-be standard available. They are
>>> not behaving exactly the same - but that is to be expected with early
>>> implementations of something that is not yet specced up. And in addition
>>> there are apps using those implementations.
>>> 
>>> For the last month or so there has been a lot of traffic expressing
>>> dislike, and the need for a re-design. I think that the responsible
>>> thing to do in that situation is to understand more on why, and how
>>> things should be changed to be better. To throw everything out and start
>>> from scratch would not be fair to those who have implementations or to
>>> those using the implementations.
>>> 
>>> And, am I the only one fearing that starting over could take a long long
>>> time? A lot of people think the current API is really bad, but that does
>>> not mean that it will be easy to agree on what a good API should look like.
>>> 
>>> So the chairs have asked for use-cases that motivate changes. We've
>>> asked for API methods in addition the the current ones that there is
>>> need for. And we have invited to a discussion on v2 of the API, but
>>> proposed to start from use-cases. I don't think that is unreasonable,
>>> but also hear that use-cases is not the right starting point.
>>> 
>>> If you have ideas or proposals (being API issues, API proposals,
>>> procedures, use-cases, etc.), please submit them to the list (regardless
>>> of if they are for v1, v2 or vN) - I'm pretty sure that good ideas will
>>> be picked up. Perhaps someone has a really clever idea on a mod of the
>>> current API that would be seen as an improvement by most?
>>> 
>>> I fully agree to Matthew that currently there is not enough detail to
>>> build interoperable implementations in the combined (over W3C and IETF)
>>> set of documents, in particular SDP details are still lacking. That must
>>> of course be addressed.
>>> 
>>> Stefan
>>> 
>>>> Matthew Kaufman
>>>> 
>>>> *From:*Peter Thatcher [mailto:pthatcher@google.com]
>>>> *Sent:* Friday, July 19, 2013 12:29 PM
>>>> *To:* cowwoc
>>>> *Cc:*public-webrtc@w3.org
>>>> *Subject:* Re: On babies and bathwater (was Re: [rtcweb] Summary of
>>>> Application Developers' opinions of the current WebRTC API and SDP as a
>>>> control surface)
>>>> 
>>>> On Fri, Jul 19, 2013 at 12:15 PM, cowwoc <cowwoc@bbs.darktech.org
>>>> <mailto:cowwoc@bbs.darktech.org>> wrote:
>>>> 
>>>>     On 19/07/2013 3:06 PM, Adam Roach wrote:
>>>> 
>>>>         On 7/19/13 13:47, Peter Thatcher wrote:
>>>> 
>>>>             I think this is the real issue at hand: You value legacy
>>>>             interop more than a usable API.
>>>> 
>>>> 
>>>>         This. *This* is why I've told you that you're misunderstanding
>>>>         everything. Don't take offense, just go back and read more
>>>>         carefully. I never said anything that implied that legacy
>>>>         interop is more valuable than a usable API. It's a nice strawman
>>>>         for you to build up and tear down, but you are arguing with a
>>>>         fictional character who is not me when you do so.
>>>> 
>>>>         What I'm trying to point out is that these goals are not at odds
>>>>         with each other. Your statement above implies that you have
>>>>         taken it as given that we can't do both -- that there is a
>>>>         tradeoff here to be made. If you take that as a fundamental
>>>>         principle, then I can see how nothing I say makes any sense.
>>>> 
>>>>         But they're not mutually exclusive goals. Keep that in mind, and
>>>>         go back to re-read what I've written.
>>>> 
>>>>          I think what Adam is trying to say is:
>>>>     http://www.joelonsoftware.com/articles/fog0000000069.html
>>>> 
>>>>          Adam, I would argue that we can improve the API incrementally
>>>>     without throwing out all the lessons we've learned to date *but*
>>>>     this means you have to be open to change.
>>>> 
>>>> 
>>>> Ironically, the thing that seems to have gotten the whole SDP discussion
>>>> reignited was that I proposed the "NoPlan JS API", which was a
>>>> completely incremental, additive approach to improving the API.  So, I'm
>>>> totally in favor of an incremental approach to improving the API.  But,
>>>> when I proposed it, I got three big pieces of feedback:
>>>> 
>>>> 1.  The anti-SDP crowd said, basically, "We don't like it because
>>>> there's still too much SDP;  Remove more".
>>>> 
>>>> 2.  The pro-SDP crowd said, basically, "We don't like it because this
>>>> isn't SDP Offer/Answer;  Don't change so much".
>>>> 
>>>> 3.  The WG leaders said, basically, "let's finish the current API before
>>>> we change anything major".
>>>> 
>>>> My hope is that 2.0 will be able to make everyone happy.
>>>> 
>>>>     It's not okay to use this as a club to silence calls for change,
>>>>     which frankly is what we've been hearing for a while: "Sit tight
>>>>     while we finish 1.0... it's just around the corner. Let's not
>>>>     discuss any changes until we get this out the door."
>>>> 
>>>> FYI, Adam just said we're "nowhere near finished yet".
>>>> 
>>>>     Gili
>>>> 
>> 
> 
>

Received on Tuesday, 23 July 2013 11:56:41 UTC