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,

     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.

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

     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.

     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.

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 Monday, 22 July 2013 16:47:41 UTC