Re: [hybi] ws and bwtp thoughts

["Thomson, Martin" <[e-mail]>]

Hi Greg,

> Needless to say that even with per message meta-data, I think we
> can do a lot better than HTTP which has a lot of request/response
> baggage in the accept-xyz headers.
>
> So I don't think that we should immediately conclude that if
> per message meta-data is supported, then we are going to see
> hundreds of extra bytes per message.

In many cases no parameters will be needed.  Thus, applications get the best of both worlds.

For many WS-like use cases, I can think of no real benefit that is gained by adding additional parameters.  We've got folks looking for more than that though.

> One suggestion I have made previously is to simply define
> another type byte for websocket that would mean the content
> is mime encoded content with standard headers terminated by
> CRLFCRLF.

I would go further and make everyone pay the 4 byte cost.

> But this would probably need either some websocket API changes
> or some serious extra header conventions to allow transparent
> sharing  of TCP/IP connections between websocket "connections",
> but it at least opens the possibility.

We should not necessarily make protocol decisions based on a draft API for that protocol.  But then, you knew that ;)

> In fact, header conventions could also be used to
> implement channels and other protocol extensions without
> needing to put them into the framing.

That was the essence of my email...  That has certain advantages from a complexity/flexibility standpoint.

> I think the cat is feeling very nervous about all
> the different types of knives that can be used !

There has to be a lolcats pic for that.  Google fails me.