This is an interesting direction to allow extensibility from browser vendors under a standard API, as the standard does not mandate any implementation language for the API.
I remember Matthew Kauffman said during the last conference call that CU-RTC can implement JSEP. If it can also implement the whole PeerConnection, could this be a way forward?
I certainly wouldn’t mind a two level API if there are no performance issues.
Thanks.
Li
-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, September 06, 2012 10:19 AM
To: public-webrtc@w3.org
Subject: Re: On the subject of complexity
On 09/04/2012 09:05 PM, Martin Thomson wrote:
> Complexity can be addressed in a number of ways. It seems that some
> folks (Ted and Cullen foremost on this thread) are convinced that it's
> a straight choice between low and high level APIs.
>
> The idea that we could trade complexity in the browser for complexity
> in the application without affecting either the availability of low
> level APIs or usability maybe did not occur. Maybe it wasn't
> convenient. Thankfully, we aren't optimizing a one-dimensional
> system.
>
> For example, the API that I posted at the start of this thread - or
> something like it - could be made part of the browser API.
>
> With that API available, it's quite likely that a demo built on the
> two APIs would be comparable in complexity... for the class of
> applications where complexity is a determining factor.
I've also heard the claim (not sure if you were the one who made it,
Martin) that the PeerConnection API could be implemented on top of the
CU-RTC API, in which case the complexity of using them would of course
be identical.
If the PeerConnection API, implemented on top of CU-RTC, can then be
part of the browser API .... that's an implementation strategy. Some
might like it.