Re: Google's position on the WebRTC API

+1 on the "Unified Plan" document.


On Tue, Jul 23, 2013 at 7:36 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

> On 22/07/2013 11:00 PM, Justin Uberti wrote:
>
>> With the compromise reached in the Unified Plan document, the group has
>> resolved one of the biggest remaining controversies for WebRTC, and cleared
>> the way for finishing up our current specs. Given the current
>> implementation state, we think it's important to complete these docs within
>> the next six months, reducing scope wherever possible to make this happen.
>> We can then refocus on what's next.
>>
>> Like other implementers, we've recognized that WebRTC has evolved
>> significantly since we started - the original goal of a very simple,
>> interoperable API has been joined by a desire for more direct, low-level
>> control. We see this as the impetus for a different approach, operating a
>> level lower than the current API. Such an API would be a fresh start and
>> address the concerns currently being discussed in this group, but should
>> also allow the current API to be layered on top of it.
>>
>> While the idea of starting this new work is exciting, just figuring out
>> what is in and out of scope will take a considerable amount of time. That's
>> why we propose scoping down and completing the current work now, and then
>> tackling our new challenge.
>>
>> Justin, for the Google WebRTC team
>>
>
> Hi Justin,
>
>     The only suggestion I would throw in is to ensure that the API you are
> publishing does not force inappropriate design constraints on the low-level
> API that will follow. Off the top of my head, I'm guessing that you can
> layer SDP on top of an API without it, but the same does not hold true for
> Offer/Answer. Hopefully someone can suggest minor changes to remove these
> constraints and still allow you to achieve the same goals.
>
>     On a side-note, I tried Googling "WebRTC Unified Plan". Unfortunately,
> I could not find a reference to this document. Care to share a link?
>
> Gili
>
>