Re: Discussing new API proposals

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 :)

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

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

     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. 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 Wednesday, 17 July 2013 17:34:47 UTC