[RTW] List is now open

[Ian Hickson]

On Sun, 10 Oct 2010, Justin Uberti wrote:
>
> My idea is that we will tie these various pieces together like a filter
> chain, i.e.
> 
> <device> -> [encoder] -> [transport] -> [decoder] -> <video>

This is basically what's in the HTML spec today:

On the sending side:

  <device> is <device>
  [encoder] is a Stream object
  [transport] is a PeerConnection object

On the receiving side:

  [transport] is a PeerConnection object
  [decoder] is a Stream object's .url attribute
  <video> is a <video>

The details are abstracted out a lot at this point; the idea is that 
future versions of the API can add specific knobs and dials to allow 
authors to control what they want to change; we can decide what to expose 
based on what people most want. This dramatically limits the complexity of 
what we have to implement, and makes it more likely we'll get interop 
sooner. However, I need to do some work on this spec to merge in the ideas 
from some of Justin's work, so this may change a bit. What will certainly 
change is the way the low-bandwidth channel maintained by the script is 
interfaced with on the PeerConnection object; I also need to move some of 
the Session stuff into the spec, e.g. sending of DTMF tones.

Work still has to happen to define how information is conveyed to the 
browser, in particular, what format the browser should expect server 
configuration to be in. We also need a spec defining how browsers use 
ICE/STUN/etc, e.g. how they identify which PeerConnection object an 
incoming connection is related to -- imagine the situation of a script 
trying to open two simultaneous connections between the same two browsers.

One thing that might make sense is for me to write a skeleton of what I 
imagine the "next layer" would look like (the spec layer that defines the 
format of the data that the browsers use to talk over the low-latency 
channel, defines how ICE/STUN/relays/etc are used, defines what the 
relays are, defines how to do video codec negotiation, defines how to 
identify which packets go with which PeerConnection, defines how to 
respond to specific API calls in terms of data on the wire, etc), and to 
then hand that off to someone who actually knows how that is all to be 
defined. Would that make sense?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'