Re: Discussing new API proposals

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.

     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.

     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.

     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.

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

Thanks,
Gili

Received on Tuesday, 16 July 2013 16:06:19 UTC