Re: API scope

On 02/06/2012 03:20 PM, Timothy B. Terriberry wrote:
> Dominique Hazael-Massieux wrote:
>> While that approach is often reasonable for protocols, and sometimes for
>> formats, I don't think it's necessarily the better one for APIs:
>
> +1
>
>> I don't have specific suggestions as to what features would need to be
>> modularized at this stage, but since there are quite a few proposals
>> under discussion (data channels, JSEP, capabilities/hints APIs, secured
>> media streams, ...), I thought it would be useful to share that
>> perspective.
>
> This is one of the reasons argued for splitting getUserMedia off (so 
> it could be developed and iterated independently of the other pieces). 
> I'll also note that the initial Chrome WebRTC implementation does not 
> have a data channel.
>
> The difficulty is that a) there are interactions between them (e.g., 
> BUNDLE in the SDP vs. whether the data channel must be negotiated, 
> whether or not the DTLS stack is always available, etc.), and b) once 
> we add something, we can never take it away.
>
> You argue b) is a reason to hold off on adding things, but it's also a 
> reason to plan for them in advance, even if we're not going to ship 
> them right away. For example, if we allow SDES (or even plain RTP) in 
> the short term because DTLS-SRTP requires more work, then we can never 
> remove them, and bid-down attacks will always be possible.
The convergence of these two viewpoints seems to be that we 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.
Seems to make sense (with the proviso that what we get implemented and 
get experience with is more likely to be useful than what we don't get 
implemented at all).
>
> 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).
Tangential: I would like to see the exact SDP messages that would "work 
right" for ROAP in the change-codec case, with an explanation of when in 
the message sequence the sender would change over. I still don't feel 
that I understand this issue fully.




>
>

Received on Tuesday, 7 February 2012 05:43:43 UTC