<br><br><div class="gmail_quote">On Mon, Oct 11, 2010 at 12:11 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Sun, 10 Oct 2010, Justin Uberti wrote:<br>
><br>
> My idea is that we will tie these various pieces together like a filter<br>
> chain, i.e.<br>
><br>
> <device> -> [encoder] -> [transport] -> [decoder] -> <video><br>
<br>
</div>This is basically what's in the HTML spec today:<br>
<br>
On the sending side:<br>
<br>
  <device> is <device><br>
  [encoder] is a Stream object<br>
  [transport] is a PeerConnection object<br>
<br>
On the receiving side:<br>
<br>
  [transport] is a PeerConnection object<br>
  [decoder] is a Stream object's .url attribute<br>
  <video> is a <video><br>
<br>
The details are abstracted out a lot at this point; the idea is that<br>
future versions of the API can add specific knobs and dials to allow<br>
authors to control what they want to change; we can decide what to expose<br>
based on what people most want. This dramatically limits the complexity of<br>
what we have to implement, and makes it more likely we'll get interop<br>
sooner. However, I need to do some work on this spec to merge in the ideas<br>
from some of Justin's work, so this may change a bit. What will certainly<br>
change is the way the low-bandwidth channel maintained by the script is<br>
interfaced with on the PeerConnection object; I also need to move some of<br>
the Session stuff into the spec, e.g. sending of DTMF tones.<br>
<br>
Work still has to happen to define how information is conveyed to the<br>
browser, in particular, what format the browser should expect server<br>
configuration to be in. We also need a spec defining how browsers use<br>
ICE/STUN/etc, e.g. how they identify which PeerConnection object an<br>
incoming connection is related to -- imagine the situation of a script<br>
trying to open two simultaneous connections between the same two browsers.<br>
<br>
One thing that might make sense is for me to write a skeleton of what I<br>
imagine the "next layer" would look like (the spec layer that defines the<br>
format of the data that the browsers use to talk over the low-latency<br>
channel, defines how ICE/STUN/relays/etc are used, defines what the<br>
relays are, defines how to do video codec negotiation, defines how to<br>
identify which packets go with which PeerConnection, defines how to<br>
respond to specific API calls in terms of data on the wire, etc), and to<br>
then hand that off to someone who actually knows how that is all to be<br>
defined. Would that make sense?<br></blockquote><div><br></div><div>Sure. As you mention, our previous discussions on the Session API are probably a good start for this. I'd be happy to work with you on the details.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
--<br>
Ian Hickson               U+1047E                )\._.,--....,'``.    fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a>       U+263A                /,   _.. \   _\  ;`._ ,.<br>
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'<br>
</font></blockquote></div><br>