RE: On the subject of complexity

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.

Received on Thursday, 6 September 2012 15:25:58 UTC