While the concerns on the server-side are overstated, the analogy to http is also questionable ... The current protocol, being a *scoket* layer protocol, is in principle different than http, which is strictly a L7 RPC protocol.<div>
<br></div><div>Is there any fundamental limitation for different UI components to share a single websocket connection, which is just another type of shared resource, e.g. among storage etc ..? Is the "shared worker" approach the only/ideal solution?</div>
<div><br></div><div>As much as it seems complicated/risky for the script to implement its own (adhoc) multiplexing, any built-in multiplexing protocol (as a L7 concern) could also limit future applications/frameworks that we are yet to find out.</div>
<div><br></div><div>- Wenbo</div><div><br></div><div><br><div class="gmail_quote">On Fri, Sep 4, 2009 at 3:28 PM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></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 Fri, Sep 4, 2009 at 1:45 AM, Ian Hickson<<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>> wrote:<br>
> 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>
> The authors still have to implement it on the server side, though.<br>
<br>
</div>Experience from HTTP shows that there are much fewer HTTP server<br>
implementing the HTTP protocol, than there are authors using those<br>
servers. I don't see that things would be dramatically different with<br>
websocket given some time to let generic servers mature.<br>
<div class="im"><br>
>> 2. There are much fewer UA implementors than website authors, so the<br>
>> level of code reuse would be much higher.<br>
><br>
> The website authors still have to do it even if the UA is the one that<br>
> codes it up on the client side.<br>
<br>
</div>Experience from HTTP shows that there are much fewer HTTP server<br>
implementing the HTTP protocol, than there are authors using those<br>
servers. I don't see that things would be dramatically different with<br>
websocket given some time to let generic servers mature.<br>
<div class="im"><br>
>> 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>
> Do we really want two different pages sharing the same TCP connection?<br>
> 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>
<br>
</div>That's what we do with HTTP today. So I would say yes.<br>
<div class="im"><br>
>> 4. If websocket is successful, websocket proxies will likely show up,<br>
>> allowing multiplexing across different users that share the same proxy.<br>
><br>
> That sounds frightening.<br>
<br>
</div>Again, HTTP benefits from this a lot today.<br>
<font color="#888888"><br>
/ Jonas<br>
</font></blockquote></div><br></div>