- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Mon, 30 Jan 2012 18:31:21 +0100
- To: Cullen Jennings <fluffy@cisco.com>, Justin Uberti <juberti@google.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Sorry for the format of my reply (crappy web access outlook) ________________________________________ From: Cullen Jennings [fluffy@cisco.com] Sent: Friday, January 27, 2012 5:19 PM To: Justin Uberti Cc: Adam Bergkvist; public-webrtc@w3.org Subject: Re: Code examples: Existing API and JSEP On Jan 26, 2012, at 9:24 PM, Justin Uberti wrote: >> >> - Special cases such as glare and multiple offers have to be handled in >> JavaScript. >> A simple example with the existing API (and ROAP) is quite powerful sice >> special >> cases are handled under the hood. >> > > Right, this is what we acknowledged as a tradeoff of JSEP; by pushing more > control into JS, more code is needed. But as you can see, the amount of > code is not that large, and this could easily be placed into a JS library. Uh, I think the coded needed is a lot more than this and I am still waiting for an answer on what it is that you can do with JSEP's "more control" Adam: Cullen is right about that the JSEP example needs more code. E.g., this example do handle the case where one side adds several streams in a row, but it doesn't include code to handle glare (or any other special case that I didn't think of). I think we need to identify where it gives more control otherwise it's just a lot of steps that you have to perform in JavaScript in a certain order. > >> >> It's also a question if PeerConnection.createOffer() and >> PeerConnection.createAnswer() >> actually can have a return value? If the browser needs to reach down into >> the platform >> to gather information these methods may need to be async and use a >> callback. >> > > Good point. I'd be interested in knowing whether anyone would need this. Yes - if you were implementing video on something like a iPhone, you would.
Received on Monday, 30 January 2012 17:31:57 UTC