Re: Discussing new API proposals

On 7/16/13 6:07 PM, cowwoc wrote:
> Hi Stefan,
>
>       First, thank you for this email. It's good to finally receive a
> formal response on the high-level status of this project.
>
> On 16/07/2013 7:44 AM, Stefan Håkansson LK wrote:
>> We welcome new proposals and ideas to be made and discussed, and think
>> this WG is the right place to do so.
>>
>> However, as outlined already last year, we think the WG should focus on
>> finalizing the current API draft (to a LC status) before starting a new
>> public/official document describing a new API. We think it has advanced
>> far already, there are working implementations and it is used by
>> application developers. Abandoning it, or slowing it down, now would be a
>> bad idea.
>
>       It is my view that the existing API was written with the mindset of
> getting the basic functionality out the door, not to mention making the
> API user friendly. I agree with you that we are nearing the end of the
> first phase (implementing basic functionality). Where we disagree is
> that this API should ever get published. I consider the existing API to
> be a proof of concept. While it is true that "it is used by application
> developers" a community poll
> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg08166.html) has
> shown that they are highly unsatisfied with it. I understand that you
> are under the impression that these "application developers" would
> resist any changes to the API at this point, but I believe this is not
> the case.

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.

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

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

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

>
>> Discussing different use cases that are hard to do with the present API,
>> and discussing approaches and ideas that would make those use cases easier
>> to achieve, would probably be an excellent exercise in distilling out the
>> main approach for a new API (or future API extensions). We welcome such
>> discussions.
>>
>> In discussing, we should distinguish carefully between three categories of
>> proposals:
>>
>> - those that would remove functionality that present applications depend
>> on, and make it hard or impossible for those applications to go on working
>
>       I don't think any of us have this goal. Although some of our
> efforts might have been misconstrued as "throw SIP out the window" we
> understand that existing use-cases must be supported in all future
> proposals. I made a concrete proposal to move us in this direction, but
> did not receive any response:
> http://lists.w3.org/Archives/Public/public-webrtc/2013Jun/0250.html
>
>> - those that move functionality between Javascript and the browser,
>> possibly requiring simple adaptation libraries to maintain the
>> functionality applications are currently using
>> - those that extend the current functionality, allowing current
>> applications to go on working.
>>
>> While respecting the need to keep APIs as clean and uncluttered as
>> possible, it should be obvious which kinds  of changes require the more
>> rigorous justification.
>>
>> The list is open for the discussions.
>>
>> Stefan for the chairs
>
>       I look forward to further discussion on this topic.

And I look forward to it too (and contributions from you)!

>
> Thanks,
> Gili
>
>

Received on Wednesday, 17 July 2013 12:20:22 UTC