- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 4 Sep 2009 18:28:16 -0400
On Fri, Sep 4, 2009 at 1:45 AM, Ian Hickson<ian at hixie.ch> wrote: > On Fri, 14 Aug 2009, Jonas Sicking wrote: >> > >> > How do you envisage multiplexing working? It's not clear to me what we >> > could do that would be easier to handle than just having the script >> > manually do the multiplexing at the application layer. What would the >> > API look like? What would the wire level look like? >> >> Some advantages of putting it in the protocol: >> >> 1. More likely the UA implementors will make the effort of implementing >> multiplexing (and doing so correctly), than that website authors will. > > The authors still have to implement it on the server side, though. Experience from HTTP shows that there are much fewer HTTP server implementing the HTTP protocol, than there are authors using those servers. I don't see that things would be dramatically different with websocket given some time to let generic servers mature. >> 2. There are much fewer UA implementors than website authors, so the >> level of code reuse would be much higher. > > The website authors still have to do it even if the UA is the one that > codes it up on the client side. Experience from HTTP shows that there are much fewer HTTP server implementing the HTTP protocol, than there are authors using those servers. I don't see that things would be dramatically different with websocket given some time to let generic servers mature. >> 3. Scripts in different tabs, and even from different sites, that >> connect to the same server would be able to share TCP/IP channel. > > Do we really want two different pages sharing the same TCP connection? > That seems like a disaster waiting to happen -- it just takes one minor > bug on the server for information to end up in the wrong channel. That's what we do with HTTP today. So I would say yes. >> 4. If websocket is successful, websocket proxies will likely show up, >> allowing multiplexing across different users that share the same proxy. > > That sounds frightening. Again, HTTP benefits from this a lot today. / Jonas
Received on Friday, 4 September 2009 15:28:16 UTC