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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.