Re: API scope

On 02/10/2012 08:09 PM, Timothy B. Terriberry wrote:
> Stefan Hakansson LK wrote:
>> On 02/07/2012 12:20 AM, Timothy B. Terriberry wrote:
>>> Similarly, it was argued at the F2F that ROAP was a subset of JSEP
>>> (though if Cullen is right and switching codecs causes a period where
>>> the receiver can't process what the sender is sending with JSEP, but not
>>> with ROAP, I don't see how that can be true), but I think it would have
>>> been hard to start with one and get to the other without working it out
>>> first. Doing that may in fact be an interesting exercise (in terms of
>>> getting more formalized semantics for things like setRemoteDescription()
>>> before moving on to those that also require modifying the SDP passed to
>>> setLocalDescription(), and separating out exactly what each one buys us
>>> in terms of our use-cases).
>>
>> Tim, could you elaborate a bit more on your proposal? I think it sounds
>> interesting, but want to understand more.
>
> I don't think I have a specific proposal, I meant it mostly as a
> thought-experiment, along the lines of what Harald said: "[W]e should
> make sure we don't add stuff in the first iteration that we aren't sure
> we can live with as permanent features of the platform."
>
> As Jim Barnett has said elsewhere (echoing what I was trying to say in
> the F2F), setLocalDescription() is currently way under-specified. In
> addition to the list of things you can change in the SDP and the
> validation that SDP must pass (which Jim pointed out), I'd add the
> semantics of what happens when you pass it two different OFFERs in a row
> (which, as I understand it, is where it departs from 3264 semantics). If
> we can move forward without having to expose those things, with the
> intention of adding them later, I think that gets us to a usable spec
> faster.

Agree fully.

>
> Unfortunately, the only way I've seen to do that is to add another API
> call that combines createOffer() and setLocalDescription() (to ensure
> the SDP is not modified between the two),

I have come to a similar conclusion. In fact, I think the browser 
should, when needed (as a result of add/removeStream, or even 
add/removeTrack on a MS attached to the PeerConnection) do that 
automatically. The reason being that every time that is done 
(add/removeStream, or even add/removeTrack) some signaling to handle 
this is needed - so the app would have to do

1. addStream (could be remove, or track addition/removal)
2. createOffer
3. setLocal

why not have 2. and 3. happen automatically?

Then we also have to figure out a way that the application can modify 
the local description. But perhaps the first step there is to understand 
what you would want to change, what would be legal, and then decide how 
(and if we want to move fast we could add that later).

(speaking strictly as a contributor)

>and adding more API to make
> something "simpler" doesn't seem like the right idea. Maybe someone else
> has a better approach.

Received on Sunday, 12 February 2012 18:36:53 UTC