On Sat, Feb 15, 2014 at 5:25 AM, Roberto Peon <grmocg@gmail.com> wrote: > Plan D makes no sense to me. It requires implementation of two separate > parsers and yields no benefit for intermediary loadbalancing > infrastructure. Arguably it additionally increases latency, since the > handshake is still preserved as written in RFC6455. > > Plan A offers some benefits for loadbalancers, etc. so long as END_SEGMENT > always correlates to the end of a message, and so seems potentially > tenable. Loadbalancers need not implement the RFC6455 parser in order to > load balance, which is a significant benefit. It is sad that there would > still be the latency of the handshake. > By tunneling, the doc intends to mean only that frames are tunneled, I think. Sorry that we didn't try to address this point it in -00 but we can drop "don't send any message before receiving response" restriction over the proposed layering though it also requires API side change to be utilized. It'll be speculative message sending (subprotocol negotiation and extension are not yet negotiated). So, if we want to make this non-speculative, we need to move these negotiation stuff into some earlier step. I don't care subprotocol much, but extensions should.
Received on Saturday, 15 February 2014 00:32:56 UTC