Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-01.txt

[John Tamplin <[e-mail]>]

On Thu, Sep 2, 2010 at 1:31 PM, Olli Pettay <[e-mail]> wrote:
> I understand what subprotocols are meant for, but while we're trying to
> stabilize the protocol, subprotocols could be used for versioning too.

So what if you want to experiment with an application subprotocol?  If
the framing is altered based on the subprotocol, then the application
can't use subprotocols itself.

> The old hixie-style framing allow all sorts for extensions. There are
> plenty of bits left for different kinds of frame types.

Well, the first problem is it doesn't support fragmentation, which is
a problem given that has been accepted as a requirement.  Second, it
uses two different types of framing for text and binary data, and many
negative opinions of having two types of framing were expressed here.
Finally, the only possible method of extension would be to define
nested opcodes, and there have been many discussions here about the
virtue of that choice relative to others.  The point of the current
framing is that it answers most of the objections that have been
raised while retaining the flexibility to define the various extension
mechanisms that have been proposed on top of it.  That allows us to
agree on the base framing, in such a way that those who don't ever
want to handle extensions can just refuse to negotiate them and ignore
them, and then those who do care can debate the merits of different
extension mechanisms.

> (And for things like multiplexing shared workers some
>  people have just said that it doesn't work without even trying.)

How can writing shared workers ever handle the case of mutliplexing
traffic in different apps?  Or aggregating traffic across an expensive
wireless link, which will then get split on the other side?  Even if
shared workers can be used to solve some of the problems multiplexing
solves, it can't solve all of them and IMHO is more complex rather
than just implementing it once in the framing layer.

-- 
John A. Tamplin
Software Engineer (GWT), Google