[whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)

[Wenbo Zhu]

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.
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?

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.

- Wenbo


On Fri, Sep 4, 2009 at 3:28 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090904/d11728ad/attachment-0002.htm>