<div>For the record, I'm perfectly happy with WebSockets not being made any more complicated for v1 (i.e. no multi-plexing), but I don't think your arguments against it are compelling at all, so I'm going to play devils advocate:</div>

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

<div class="im">> > What would the wire level look like?</div><div class="im">
><br>
> It could be as simple as this: An extra byte or two at the beginning of<br>
> every message that says which "channel" is transmitting.  A way to send<br>
> control messages, two of which would be used to open and close channels.<br>
<br>
</div>I don't understand why we'd do that rather than just use two TCP<br>
connections.<br></blockquote><div><br></div><div>Latency and limits within the OS.</div><div><br></div><div>On Fri, Sep 4, 2009 at 2:45 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>></span> wrote:<br>

<div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<div class="im">On Fri, 14 Aug 2009, Jonas Sicking wrote:<br>> ><br>> > How do you envisage multiplexing working? It's not clear to me what we<br>> > could do that would be easier to handle than just having the script<br>

> > manually do the multiplexing at the application layer. What would the<br>> > API look like? What would the wire level look like?<br>><br>> Some advantages of putting it in the protocol:<br>><br>> 1. More likely the UA implementors will make the effort of implementing<br>

> multiplexing (and doing so correctly), than that website authors will.<br><br></div>The authors still have to implement it on the server side, though.<br></blockquote><div><br></div><div>You could have it be an optional feature.  Most websites are hosted through just a couple servers like how most websites are viewed in just a couple browsers.  Its not like every web developer would have to implement their own server.  I don't understand why you think this server side argument is so compelling</div>

<div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<div class="im">> 3. Scripts in different tabs, and even from different sites, that<br>> connect to the same server would be able to share TCP/IP channel.<br><br></div>Do we really want two different pages sharing the same TCP connection?<br>

</blockquote><div><br></div><div>Once again yes, for latency reasons.</div><div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

That seems like a disaster waiting to happen -- it just takes one minor<br>bug on the server for information to end up in the wrong channel.<br></blockquote><div><br></div><div>You could say the same thing about so many parts of the networking stack.  An off by one error here or there could easily mis-route a message to the wrong app/router/etc.  But they generally don't.  When there are worries about correctness, you make test suites.  I really don't understand why you think this is so risky.</div>

<div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

Seems reasonable, though I am skeptical about throwing this level of<br>complexity at Web authors, and I don't really know how we would expose it<br>at the API level.<br></blockquote><div><br></div><div>Why is this necessary?  It seems like when you open multiple WebSocket connections to the same server, they could transparently share the same connection.</div>

</div></div></div>