Re: [hybi] web socket protocol in "last call"?

[Greg Wilkins <[e-mail]>]

Infinity Linden (Meadhbh Hamrick) wrote:
> WS is essentially unusable for me in it's current form. or rather, i
> could use it, but why? my use case of establishing reverse
> request-response semantic recognizable by intermediaries that supports
> channel multiplexing is possible over WS, but then again, it's also
> possible by extending HTTP, so why not just do that?

I completely agree with this sentiment.   WS is usable, but provides
no significant benefit over HTTP other than a warm philosophical
feeling that you are not abusing HTTP, is a little more byte
efficient and marginally better latency.

But it is not going to scale for my use-cases because of the
connection bloat.   It's going to break all the load balancers
I work with, and the SSL offloaders and most other network
infrastructure.

I'll be interested to see what happens when intermediaries
notice ws trying to run around them.  Will they support it or
block it?   My money is on the later.

If it becomes a standard as is, we will support it... but hide
it in the basement, under the stairs behind a sign that says
"beware of the leopard".    It will be a novelty like HTTP
pipelining - you can turn it on and play with it, but will
not seriously consider using it in deployment other than in
very specific circumstances.

Failing consensus on the protocol, I would have really liked the
opportunity of having a service provider API in the browser - so
I could intercept standard ws API and transport it over something
that would work my use-cases, or inserting layers between
app API and transport.

Pity.  Opportunity lost.

regards