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

[Jeremy Orlow]

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:

On Fri, Sep 4, 2009 at 2:37 PM, Ian Hickson <ian at hixie.ch> wrote:

> > > What would the wire level look like?
> >
> > It could be as simple as this: An extra byte or two at the beginning of
> > every message that says which "channel" is transmitting.  A way to send
> > control messages, two of which would be used to open and close channels.
>
> I don't understand why we'd do that rather than just use two TCP
> connections.
>

Latency and limits within the OS.

On Fri, Sep 4, 2009 at 2:45 PM, 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.
>

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

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

Once again yes, for latency reasons.


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

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.


> Seems reasonable, though I am skeptical about throwing this level of
> complexity at Web authors, and I don't really know how we would expose it
> at the API level.
>

Why is this necessary?  It seems like when you open multiple WebSocket
connections to the same server, they could transparently share the same
connection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090904/6836ebbf/attachment-0002.htm>