Re: Giving the Framing Layer a real name

No one said that subprotocols would not still be possible on top of
the same framing mechanism. Mark's question was about naming only, not
design. There is still a good design separation between the HTTP
semantics and the framing layer, and the framing layer would still be
reusable beyond just carrying http semantics.

On Wed, Feb 27, 2013 at 10:51 AM, Roberto Peon <grmocg@gmail.com> wrote:
> Then you can't do websockets, etc or whatever other protocol (maybe video?,
> who knows) the web platform decides to do in the future on the same
> socket/session.
>
> That would be a poor tradeoff.. and for what gain?
> What is the additional complexity of having the framing allow for non HTTP
> semantics?
> -=R
>
>
> On Wed, Feb 27, 2013 at 10:13 AM, James M Snell <jasnell@gmail.com> wrote:
>>
>> +1
>>
>> On Feb 27, 2013 10:03 AM, "Martin Thomson" <martin.thomson@gmail.com>
>> wrote:
>>>
>>> On 27 February 2013 00:49, Mike Belshe <mike@belshe.com> wrote:
>>> > My vote would be to nuke the layering and instead fold section 4 (the
>>> > HTTP
>>> > Layering) into the appropriate sections of the framing layer.  Trying
>>> > to
>>> > make these generic frames seems like a distraction, and it would be
>>> > simpler
>>> > for folks to read if these were just the basics of HTTP framing.
>>>
>>> I said as much to mark in private: the framing layer is for HTTP.  A
>>> name implies that it might stand alone.  That's not going to be true.
>>> The work to make it true is not worthwhile either.
>>>
>

Received on Wednesday, 27 February 2013 18:57:18 UTC