Re: Discussing new API proposals

On 7/17/13 7:34 PM, cowwoc wrote:
> On 17/07/2013 8:19 AM, Stefan Håkansson LK wrote:
>> No, I don't think they would resist any changes to the API, but I think
>> changes should be well motivated, and further avoid breaking working
>> applications (if possible). And I think implementers (who have working
>> implementations out there) also like changes to be well motivated.
>
>       We are in agreement. I am pushing very hard for a design document
> that will link use-cases to design decisions and concrete API methods.
>
>>>         Application developers (which I interpret as developers without
>>> telecom experience) have, by and large, been playing with WebRTC and
>>> have not deployed production software on it. Yes, some WebRTC
>>> applications have been deployed in production but we're talking about a
>>> handful of applications versus the hundred of thousands which you can
>>> expect once Version 1.0 is published. You have the rare opportunity to
>>> fix the API today, an opportunity that you will *not* have once hundreds
>>> of thousands of applications are in production.
>> On the other hand we have people using it, and counting on (a somewhat)
>> timely delivery of it.
>
>       As soon as possible, but not a minute sooner :) I too have
> commercial interests riding on WebRTC 1.0 being released sooner rather
> than later. That being said, if we don't do this right there won't
> WebRTC 2.0. Clunky technologies have a history of being replaced (they
> cause pain, people come in and replace them). Let's get this right,
> otherwise we'll be forced to rewrite our applications anyway.
>
>>>         There will be a price to pay if you release the current API as-is:
>>> you will have to support it forever and future designs will be crippled
>>> as a result of having to provide backwards compatibility for this
>>> version. When making design decisions I often ask myself: "Will it cost
>>> substantially more to add this feature in the future?". If the answer is
>>> no, I know I have the option of deferring it. I believe that in this
>>> particular case, there *is* a substantial cost to deferring design
>>> changes to WebRTC 2.0.
>> I agree that it would have to be supported for a long time, but it is
>> not to be taken for granted IMO that a WebRTC 2.0 API must build on
>> WebRTC 1.0. Sure, it could be extensions to the current API, but it
>> could also be something new that lives in parallel.
>
>       You will find it very hard (I think impossible) to do so. Anyway,
> let's say you are right... aren't we better off having 100 developers
> rewrite their applications today than 1,000,000 tomorrow?
>
>>
>>>         Furthermore, I would argue that although individual vendors
>>> (Chrome, FireFox) have existing functionality implemented under the
>>> hood, there are gaping holes in the specification (SDP specification,
>>> for example) which make it extremely difficult for other vendors and
>>> integrators from jumping on board. You will eventually plug this hole,
>>> but my point is that 1.0 isn't really around the corner as you believe.
>>> The schedule has already slipped a lot and will continue to do so. We
>>> shouldn't be using the argument that "1.0 is around the corner" to block
>>> legitimate proposals if it can be proven that deferring them to 2.0 will
>>> be very costly.
>> I agree to that there is a lot remaining to be specced regarding SDP.
>> But as said above, well motivated changes for 1.0 should of course be
>> considered for adoption (without delaying too much).
>
>       I'd like to apologize in advance for the upcoming tough love :)

No problem!

>
>       "As defined in its charter, the mission of the Web Real-Time
> Communications Working Group, created in May 2011, is to define
> client-side APIs to enable Real-Time Communications in Web browser" -
> Source: http://www.w3.org/2011/04/webrtc/
>
>       The question is: who is your target audience? My understanding is
> that WebRTC is targetting web developers; otherwise, please rename it as
> "TelecomRTC".
>
>       In my opinion, much of the delay is the result of the broken
> development process adopted by the WG (poor documentation, ignoring
> community feedback, etc). If you adopt the right process, you will get
> WebRTC 1.0 as soon as humanly possible, but not a minute sooner. The WG
> is using the fact that "1.0 is around the corner" as an excuse for
> pushing their agenda on the community. The fact of the matter is, "1.0
> for web developers" is not around the corner, not even close.
>
>       93% of the application developer community has stated that they
> "need a better API long-term" - Source:
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg08166.html
>
>       To me, that means that 93% of the community is unsatisfied with the
> existing API. The poll goes on to mention that 54% of them define the
> existing API as "Horrible/intolerable for 1.0". That's a lot of hate
> (not just mild dislike).

One thing is to agree on that disliking (or stronger) something. But 
agreeing on a design replacing the current one can take a very long time.

>
>       So to reiterate: 1.0 is not around the corner and the existing API
> is unacceptable in its current form.

My personal opinion is still that the best we can do is to finalize 1.0 
based on the current design. And that includes specifying all the things 
needed to be able to do interoperable implementations (and perhaps scope 
down if needed). If we start from scratch things could take a long time.

>
>       See the bottom of
> http://lists.w3.org/Archives/Public/public-webrtc/2013Jul/0225.html and
> http://lcsd05.cs.tamu.edu/slides/keynote.pdf slide 6 for an explanation
> of what I'm looking for.
>
>> The current approach for 1.0 is to use SDP, but if someone contributes a
>> (detailed) proposal that takes us faster to the goal of a stable spec,
>> maintains functionality and still would be possible to translate to/from
>> SDP, then I think people would listen. My personal view is that we
>> should get to a stable 1.0 ASAP (and therefore I would like to change as
>> few assumptions and design choices as possible), and if there are things
>> that make that faster we should consider them. That said, the devil is
>> often i the details, and something that looks simpler at surface can
>> prove to take a lot of effort when you start getting into the bits and
>> pieces.
>
>       It is extremely difficult to propose alternatives unless/until you
> document your design decisions and link them to the use-cases that
> justify them.

I don't get this. If the current design is so broken as claimed, then 
the design is probably based on bad decisions - so what would be the 
gain in writing them up in a document?  BTW, I think the decisions made 
can be tracked down by reading existing documents, minutes of meetings 
and mail list traffic (in IETF and W3C space).

> As Robin mentioned at
> http://lists.w3.org/Archives/Public/public-webrtc/2013Jul/0220.html the
> current documentation mixes implementation details (SDP) with design
> decisions and use-cases. We need a truly high-level design document
> unencumbered with any implementation details. On that note, please see
> http://lcsd05.cs.tamu.edu/slides/keynote.pdf slide 15 :)
>
> Gili
>

Received on Thursday, 18 July 2013 11:02:44 UTC