Re: WebSocket over HTTP/2.0

>
> 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. I dislike that this would still
> include much of the silliness in RFC6455 w.r.t. frame extensions.

I think Plan A in the draft doesn't offers benefits for loadbalancers. Once
Plan A did, but I removed the functionality at [1].
However, we can recover the functionality I think.

IIUC we can discuss the opening handshake independently from the framing
plan at [2].
As I said before, I think you like Plan C. If not, can you share you
thoughts?

I too wondered why there was a need to tunnel thewebsocketprotocol as
> opposed to creating a way to map the semantics efficiently.

Martin, let me confirm.
Does your "a way to map the semantics efficiently" mean Plan C? Or you have
another idea?

Thanks,

[1]: http://www.ietf.org/mail-archive/web/hybi/current/msg10403.html
[2]: http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0551.html



On Sat, Feb 15, 2014 at 6:49 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 14 February 2014 12:25, Roberto Peon <grmocg@gmail.com> wrote:
> > I am completely uninterested in any option that keeps full RFC6455
> semantics
> > (frame extensions make zero sense) without significant ofsetting
> benefits,
> > and I would work to ensure such was not again created at IETF, and would
> > work to ensure that it was not implemented at Google.
>
> I too wondered why there was a need to tunnel thewebsocketprotocol as
> opposed to creating a way to map the semantics efficiently.
>