Re: API scope

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.

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).

Received on Monday, 6 February 2012 23:25:21 UTC