#603: Frame layout

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

#603: Frame layout

Nottingham, Mark
<https://github.com/http2/http2-spec/issues/603>

It doesn’t seem like there is consensus to adopt a change here; as many have pointed out, our protocol is not aligned anyway, and the other gains are marginal at best.

Anyone feel strongly about this still, or can we WONTFIX?


--
Mark Nottingham    [hidden email]   http://www.mnot.net/


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Roy T. Fielding
On Sep 26, 2014, at 9:02 AM, Nottingham, Mark wrote:

> <https://github.com/http2/http2-spec/issues/603>
>
> It doesn’t seem like there is consensus to adopt a change here; as many have pointed out, our protocol is not aligned anyway, and the other gains are marginal at best.
>
> Anyone feel strongly about this still, or can we WONTFIX?

I still feel strongly about it, in the sense that the current protocol
design is rather hideous, in my opinion.  The effect is more complex
implementations, which will impact high-speed processing (particularly
when used for non-network communication).

However, this is a design choice.  If I want better design choices,
I can make them in my own protocols.

....Roy


Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Matthew Kerwin
In reply to this post by Nottingham, Mark
On 27 September 2014 02:02, Nottingham, Mark <[hidden email]> wrote:
<https://github.com/http2/http2-spec/issues/603>

It doesn’t seem like there is consensus to adopt a change here; as many have pointed out, our protocol is not aligned anyway, and the other gains are marginal at best.

Anyone feel strongly about this still, or can we WONTFIX?


​If it were earlier in the process I'd push to move flags out of the common header, but here and now I don't know that it's worth it. It's ugly, potentially confusing, but it works.​


--
  Matthew Kerwin
  http://matthew.kerwin.net.au/
Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Greg Wilkins-3
I too feel strongly about the flawed framing layer. However I've huffed and puffed and the house has not fallen down!

So I guess WONTFIX is appropriate (rather than RESOLVED).

--
Greg Wilkins <[hidden email]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.
Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Amos Jeffries-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 27/09/2014 12:06 p.m., Greg Wilkins wrote:
> I too feel strongly about the flawed framing layer. However I've
> huffed and puffed and the house has not fallen down!
>
> So I guess WONTFIX is appropriate (rather than RESOLVED).
>

Ditto.

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUJkclAAoJELJo5wb/XPRjUZcH/RtBMoJFrSWYoZ4T4MniaV18
iReypductwSwN1TU9K53fSXwd8qhedXMKtICqQg0cAChO7bncn6YGQBOY2AQwG1j
6fnQVwOrD0VrFRVYcEIHWPam8vNaBcoG9eGiMKgNxiIi6YXFfjI3JpU3qs/7wWCi
df/ZRq8WCARmzJu0eBRb2bXS83KLdFAiIyIDfZGXyURwMRGFv1+AqkigVVOoX6JR
pwL7HidWvh7Ra47atkbh84f32n1s0PKegW1+IVIQfSkjn9v+C9tezOBksGgjc1HD
6t3OkVhCcwosh7EJHBpGuyXVmWTf5lurlauAe9MYn4vw5QS9IMF0ybAy07g79Lw=
=vYrj
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Poul-Henning Kamp
In reply to this post by Roy T. Fielding
--------
In message <[hidden email]>, "Roy T. Fielding" w
rites:

>On Sep 26, 2014, at 9:02 AM, Nottingham, Mark wrote:
>
>> <https://github.com/http2/http2-spec/issues/603>
>>=20
>> It doesn=92t seem like there is consensus to adopt a change here; as =
>many have pointed out, our protocol is not aligned anyway, and the other =
>gains are marginal at best.
>>=20
>> Anyone feel strongly about this still, or can we WONTFIX?
>
>I still feel strongly about it, in the sense that the current protocol
>design is rather hideous, in my opinion.  The effect is more complex
>implementations, which will impact high-speed processing (particularly
>when used for non-network communication).

I'm with Roy here.  I think the proposed change should be made.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Reply | Threaded
Open this post in threaded view
|

RE: #603: Frame layout

K.Morgan
On Saturday,27 September 2014 07:42, [hidden email] wrote:

> In message <[hidden email]>, "Roy T. Fielding" writes:
>>On Sep 26, 2014, at 9:02 AM, Nottingham, Mark wrote:
>>
>>> <https://github.com/http2/http2-spec/issues/603>
>>>=20
>>> It doesn=92t seem like there is consensus to adopt a change here; as
>>>=
>>many have pointed out, our protocol is not aligned anyway, and the
>>other = gains are marginal at best.
>>>=20
>>> Anyone feel strongly about this still, or can we WONTFIX?
>>
>>I still feel strongly about it, in the sense that the current protocol
>>design is rather hideous, in my opinion.  The effect is more complex
>>implementations, which will impact high-speed processing (particularly
>>when used for non-network communication).
>
>I'm with Roy here.  I think the proposed change should be made.
>

I'm with PHK and Roy. I think the proposed change should be made.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Daniel Stenberg
In reply to this post by Nottingham, Mark
On Fri, 26 Sep 2014, Nottingham, Mark wrote:

> <https://github.com/http2/http2-spec/issues/603>
>
> It doesn’t seem like there is consensus to adopt a change here; as many have
> pointed out, our protocol is not aligned anyway, and the other gains are
> marginal at best.
>
> Anyone feel strongly about this still, or can we WONTFIX?

I think we should put this suggestion in the queue of things to do with the
binary format if we for some reason are lead into changing the format for some
other and more important reason. I don't think these stated motivations are
enough to (yet again) break the binary format.

--

  / daniel.haxx.se
Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Poul-Henning Kamp
--------
In message <[hidden email]>, Daniel Stenberg
 writes:

>I think we should put this suggestion in the queue of things to do with the
>binary format if we for some reason are lead into changing the format for some
>other and more important reason. I don't think these stated motivations are
>enough to (yet again) break the binary format.

I continually amazes me that backwards compatibility with a handful
of prototype implementations is used as an argument against improving
the successor to the worlds most widely used protocol.

History is littered with crappy decisions which could have been made
better for trivial cost at the right time and place, but because of
shortsightedness were not, causing almost unlimited grief later on.

The framing-layer of HTTP/2 should be given particular attention,
since it would be to everybodys huge advantage that it also be good
enough for HTTP/3 etc.

Roy and many others have repeatedly pointed out that the current
framing is a mess and that it should be cleaned up, formalized and
made future proof.

The fact that pretty much everybody is able to jot down a better,
cleaner and more orthogonal framing layer in a matter of minutes,
should be considered highly embarrasing.

Is that really the reception you want HTTP/2 to get ?

   "Huh ?  I could do that better in 30 seconds, here, let me show you..."

Just because five or ten random people have implemented the draft
at present is no excuse not to do the best job we can, before
hundreds or evne thousands of other people will have to implement
HTTP/2.0



--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Robert Collins
In reply to this post by Daniel Stenberg
On 29 September 2014 21:23, Daniel Stenberg <[hidden email]> wrote:

> On Fri, 26 Sep 2014, Nottingham, Mark wrote:
>
>> <https://github.com/http2/http2-spec/issues/603>
>>
>> It doesn’t seem like there is consensus to adopt a change here; as many
>> have pointed out, our protocol is not aligned anyway, and the other gains
>> are marginal at best.
>>
>> Anyone feel strongly about this still, or can we WONTFIX?
>
>
> I think we should put this suggestion in the queue of things to do with the
> binary format if we for some reason are lead into changing the format for
> some other and more important reason. I don't think these stated motivations
> are enough to (yet again) break the binary format.

If we are going to change it, can we make sure that the websockets
draft will have enough frame types available- I've only just started
reviewing it, but it would be tragic to shrink the number of frame
types just as one of the most obviously predictable additional users
of the transport layer starts to come onboard.

-Rob

--
Robert Collins <[hidden email]>
Distinguished Technologist
HP Converged Cloud

Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Simpson, Robby (GE Energy Management)
In reply to this post by Poul-Henning Kamp
On 9/29/14, 4:46 AM, "Poul-Henning Kamp" <[hidden email]> wrote:


>--------
>In message <[hidden email]>, Daniel
>Stenberg
> writes:
>
>>I think we should put this suggestion in the queue of things to do with
>>the
>>binary format if we for some reason are lead into changing the format
>>for some
>>other and more important reason. I don't think these stated motivations
>>are
>>enough to (yet again) break the binary format.
>
>I continually amazes me that backwards compatibility with a handful
>of prototype implementations is used as an argument against improving
>the successor to the worlds most widely used protocol.

+1

I'm implementing HTTP/2 because I believe it will be successful, widely
used, efficient, and long-lasting.  At this stage, if there are changes
that can be made to increase those qualities, I will _gladly_ update my
implementation.

If someone is implementing a draft, they should be willing to update that
implementation until the standard is finalized.  Otherwise, they should
wait to implement.

Granted, I haven't been actively participating from the beginning and may
be missing out on the fatigue, but my experience thus far has been
resistance to any real change.  To me ironic, since I waited this long to
implement as I knew I only had so many cycles..


Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Daniel Stenberg
On Mon, 29 Sep 2014, Simpson, Robby (GE Energy Management) wrote:

> I'm implementing HTTP/2 because I believe it will be successful, widely
> used, efficient, and long-lasting.  At this stage, if there are changes that
> can be made to increase those qualities, I will _gladly_ update my
> implementation.
>
> If someone is implementing a draft, they should be willing to update that
> implementation until the standard is finalized.  Otherwise, they should wait
> to implement.

I don't mind changing my (or others) code to adapt to changes in the protocol
spec. I've been on this journey from the start and I'm one of those who have
adapted code many times already and I have the feeling I will do more of that.
I'm not afraid of changing code when it's necessary.

I want a protocol to implement so I want the HTTP/2 spec to settle down, and
therefore I object aginst nit-picking details that in my mind don't have any
particular impact in the protocol's ability to succeeed and that aren't very
important to make the protocol easier to implement. I just don't consider that
minor polish worth the extra time, effort and interop work that will follow.

But if there's any other actual - REAL - change that will go in that changes
the format anyway, then I won't mind seeing these framing changes as well as
then we've already broken the seal anyway and can just as well do that change
too.

--

  / daniel.haxx.se

Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Michaela LaVan
Came here to say something similar, but Daniel beat me to the punch.

As an implementer I am strongly disinclined to make what are essentially aesthetic changes to the frame layout at this point.  Even seemingly minor changes in the most recent draft cost the working group weeks of interop data while we ironed out the bugs and got everyone on the same page. To me, the changes Roy is proposing are not worth the setbacks to our timeline that they would incur.

Like everyone else here I believe in the potential of HTTP/2 and want it to succeed. Right now the biggest threat to our goal of widespread adoption is not frame header field order or byte misalignment. It's getting to the end of 2014 and not having a protocol to ship.

On Mon, Sep 29, 2014 at 2:48 PM, Daniel Stenberg <[hidden email]> wrote:
On Mon, 29 Sep 2014, Simpson, Robby (GE Energy Management) wrote:

I'm implementing HTTP/2 because I believe it will be successful, widely used, efficient, and long-lasting.  At this stage, if there are changes that can be made to increase those qualities, I will _gladly_ update my implementation.

If someone is implementing a draft, they should be willing to update that implementation until the standard is finalized.  Otherwise, they should wait to implement.

I don't mind changing my (or others) code to adapt to changes in the protocol spec. I've been on this journey from the start and I'm one of those who have adapted code many times already and I have the feeling I will do more of that. I'm not afraid of changing code when it's necessary.

I want a protocol to implement so I want the HTTP/2 spec to settle down, and therefore I object aginst nit-picking details that in my mind don't have any particular impact in the protocol's ability to succeeed and that aren't very important to make the protocol easier to implement. I just don't consider that minor polish worth the extra time, effort and interop work that will follow.

But if there's any other actual - REAL - change that will go in that changes the format anyway, then I won't mind seeing these framing changes as well as then we've already broken the seal anyway and can just as well do that change too.

--

 / daniel.haxx.se


Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Jason Greene
I disagree that Roy’s changes are aesthetic; they do have tangible benefits. Even if they were though, minor changes to make a spec cleaner can still have large effect, by improving the quality of implementation (namely how long it takes to get right), which directly contributes to uptake and interoperability.

That said I think its reasonable to ship something thats not as ideal as it could be, and defer any sort of framing revamp to HTTP/3. The next time around, those of us that were late to the process will have learned our lesson and be early :)

On Sep 29, 2014, at 3:31 PM, Michaela LaVan <[hidden email]> wrote:

> Came here to say something similar, but Daniel beat me to the punch.
>
> As an implementer I am strongly disinclined to make what are essentially aesthetic changes to the frame layout at this point.  Even seemingly minor changes in the most recent draft cost the working group weeks of interop data while we ironed out the bugs and got everyone on the same page. To me, the changes Roy is proposing are not worth the setbacks to our timeline that they would incur.
>
> Like everyone else here I believe in the potential of HTTP/2 and want it to succeed. Right now the biggest threat to our goal of widespread adoption is not frame header field order or byte misalignment. It's getting to the end of 2014 and not having a protocol to ship.
>
> On Mon, Sep 29, 2014 at 2:48 PM, Daniel Stenberg <[hidden email]> wrote:
> On Mon, 29 Sep 2014, Simpson, Robby (GE Energy Management) wrote:
>
> I'm implementing HTTP/2 because I believe it will be successful, widely used, efficient, and long-lasting.  At this stage, if there are changes that can be made to increase those qualities, I will _gladly_ update my implementation.
>
> If someone is implementing a draft, they should be willing to update that implementation until the standard is finalized.  Otherwise, they should wait to implement.
>
> I don't mind changing my (or others) code to adapt to changes in the protocol spec. I've been on this journey from the start and I'm one of those who have adapted code many times already and I have the feeling I will do more of that. I'm not afraid of changing code when it's necessary.
>
> I want a protocol to implement so I want the HTTP/2 spec to settle down, and therefore I object aginst nit-picking details that in my mind don't have any particular impact in the protocol's ability to succeeed and that aren't very important to make the protocol easier to implement. I just don't consider that minor polish worth the extra time, effort and interop work that will follow.
>
> But if there's any other actual - REAL - change that will go in that changes the format anyway, then I won't mind seeing these framing changes as well as then we've already broken the seal anyway and can just as well do that change too.
>
> --
>
>  / daniel.haxx.se
>
>

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


Reply | Threaded
Open this post in threaded view
|

RE: #603: Frame layout

Rob Trace
As an implementer we are also not interested in changing the frame layout. This is not about taking the time to change code.  It is simply that we are not seeing enough benefit to make this change at this point and would rather continue working on interoperability and shipping the standard.

Thanks!!

-Rob

-----Original Message-----
From: Jason Greene [mailto:[hidden email]]
Sent: Monday, September 29, 2014 2:56 PM
To: Michaela LaVan
Cc: Daniel Stenberg; Simpson, Robby (GE Energy Management); Poul-Henning Kamp; Nottingham, Mark; HTTP Working Group
Subject: Re: #603: Frame layout

I disagree that Roy's changes are aesthetic; they do have tangible benefits. Even if they were though, minor changes to make a spec cleaner can still have large effect, by improving the quality of implementation (namely how long it takes to get right), which directly contributes to uptake and interoperability.

That said I think its reasonable to ship something thats not as ideal as it could be, and defer any sort of framing revamp to HTTP/3. The next time around, those of us that were late to the process will have learned our lesson and be early :)

On Sep 29, 2014, at 3:31 PM, Michaela LaVan <[hidden email]> wrote:

> Came here to say something similar, but Daniel beat me to the punch.
>
> As an implementer I am strongly disinclined to make what are essentially aesthetic changes to the frame layout at this point.  Even seemingly minor changes in the most recent draft cost the working group weeks of interop data while we ironed out the bugs and got everyone on the same page. To me, the changes Roy is proposing are not worth the setbacks to our timeline that they would incur.
>
> Like everyone else here I believe in the potential of HTTP/2 and want it to succeed. Right now the biggest threat to our goal of widespread adoption is not frame header field order or byte misalignment. It's getting to the end of 2014 and not having a protocol to ship.
>
> On Mon, Sep 29, 2014 at 2:48 PM, Daniel Stenberg <[hidden email]> wrote:
> On Mon, 29 Sep 2014, Simpson, Robby (GE Energy Management) wrote:
>
> I'm implementing HTTP/2 because I believe it will be successful, widely used, efficient, and long-lasting.  At this stage, if there are changes that can be made to increase those qualities, I will _gladly_ update my implementation.
>
> If someone is implementing a draft, they should be willing to update that implementation until the standard is finalized.  Otherwise, they should wait to implement.
>
> I don't mind changing my (or others) code to adapt to changes in the protocol spec. I've been on this journey from the start and I'm one of those who have adapted code many times already and I have the feeling I will do more of that. I'm not afraid of changing code when it's necessary.
>
> I want a protocol to implement so I want the HTTP/2 spec to settle down, and therefore I object aginst nit-picking details that in my mind don't have any particular impact in the protocol's ability to succeeed and that aren't very important to make the protocol easier to implement. I just don't consider that minor polish worth the extra time, effort and interop work that will follow.
>
> But if there's any other actual - REAL - change that will go in that changes the format anyway, then I won't mind seeing these framing changes as well as then we've already broken the seal anyway and can just as well do that change too.
>
> --
>
>  / daniel.haxx.se
>
>

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat



Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Nicholas Hurley
In reply to this post by Michaela LaVan
Yet another implementer not interested in changing the frame layout. Not only will it slow down our timeline, and break interop (again), but I'm not convinced there are any benefits to the change, and there may in fact be drawbacks.
 
 
On Mon, Sep 29, 2014, at 13:31, Michaela LaVan wrote:
Came here to say something similar, but Daniel beat me to the punch.
 
As an implementer I am strongly disinclined to make what are essentially aesthetic changes to the frame layout at this point.  Even seemingly minor changes in the most recent draft cost the working group weeks of interop data while we ironed out the bugs and got everyone on the same page. To me, the changes Roy is proposing are not worth the setbacks to our timeline that they would incur.
 
Like everyone else here I believe in the potential of HTTP/2 and want it to succeed. Right now the biggest threat to our goal of widespread adoption is not frame header field order or byte misalignment. It's getting to the end of 2014 and not having a protocol to ship.
 
On Mon, Sep 29, 2014 at 2:48 PM, Daniel Stenberg <[hidden email]> wrote:
On Mon, 29 Sep 2014, Simpson, Robby (GE Energy Management) wrote:

I'm implementing HTTP/2 because I believe it will be successful, widely used, efficient, and long-lasting.  At this stage, if there are changes that can be made to increase those qualities, I will _gladly_ update my implementation.

If someone is implementing a draft, they should be willing to update that implementation until the standard is finalized.  Otherwise, they should wait to implement.

I don't mind changing my (or others) code to adapt to changes in the protocol spec. I've been on this journey from the start and I'm one of those who have adapted code many times already and I have the feeling I will do more of that. I'm not afraid of changing code when it's necessary.

I want a protocol to implement so I want the HTTP/2 spec to settle down, and therefore I object aginst nit-picking details that in my mind don't have any particular impact in the protocol's ability to succeeed and that aren't very important to make the protocol easier to implement. I just don't consider that minor polish worth the extra time, effort and interop work that will follow.

But if there's any other actual - REAL - change that will go in that changes the format anyway, then I won't mind seeing these framing changes as well as then we've already broken the seal anyway and can just as well do that change too.

--

 / daniel.haxx.se
 
 
--
Peace,
-Nick
 
Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Simpson, Robby (GE Energy Management)
In reply to this post by Michaela LaVan
I do not see these changes as aesthetic.  To me, having flags as part of the frame header when they are very much dependent on the frame type is problematic.  Flags in the frame header should be type-agnostic.  This then allows the individual frames (and extensions) to define flags however they may need them in their own payloads.  This also allows future type-agnostic flags to be defined (should we need them) without having to worry that flags have already been claimed by extensions.

And then you get the aesthetics (and alignment) for free!  :-)

From: Michaela LaVan <[hidden email]<mailto:[hidden email]>>
Date: Monday, September 29, 2014 at 4:31 PM
To: Daniel Stenberg <[hidden email]<mailto:[hidden email]>>
Cc: Charles Simpson <[hidden email]<mailto:[hidden email]>>, Poul-Henning Kamp <[hidden email]<mailto:[hidden email]>>, "Nottingham, Mark" <[hidden email]<mailto:[hidden email]>>, HTTP Working Group <[hidden email]<mailto:[hidden email]>>
Subject: Re: #603: Frame layout

Came here to say something similar, but Daniel beat me to the punch.

As an implementer I am strongly disinclined to make what are essentially aesthetic changes to the frame layout at this point.  Even seemingly minor changes in the most recent draft cost the working group weeks of interop data while we ironed out the bugs and got everyone on the same page. To me, the changes Roy is proposing are not worth the setbacks to our timeline that they would incur.

Like everyone else here I believe in the potential of HTTP/2 and want it to succeed. Right now the biggest threat to our goal of widespread adoption is not frame header field order or byte misalignment. It's getting to the end of 2014 and not having a protocol to ship.

On Mon, Sep 29, 2014 at 2:48 PM, Daniel Stenberg <[hidden email]<mailto:[hidden email]>> wrote:
On Mon, 29 Sep 2014, Simpson, Robby (GE Energy Management) wrote:

I'm implementing HTTP/2 because I believe it will be successful, widely used, efficient, and long-lasting.  At this stage, if there are changes that can be made to increase those qualities, I will _gladly_ update my implementation.

If someone is implementing a draft, they should be willing to update that implementation until the standard is finalized.  Otherwise, they should wait to implement.

I don't mind changing my (or others) code to adapt to changes in the protocol spec. I've been on this journey from the start and I'm one of those who have adapted code many times already and I have the feeling I will do more of that. I'm not afraid of changing code when it's necessary.

I want a protocol to implement so I want the HTTP/2 spec to settle down, and therefore I object aginst nit-picking details that in my mind don't have any particular impact in the protocol's ability to succeeed and that aren't very important to make the protocol easier to implement. I just don't consider that minor polish worth the extra time, effort and interop work that will follow.

But if there's any other actual - REAL - change that will go in that changes the format anyway, then I won't mind seeing these framing changes as well as then we've already broken the seal anyway and can just as well do that change too.

--

 / daniel.haxx.se<http://daniel.haxx.se>



Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Nottingham, Mark
In reply to this post by Nottingham, Mark
I'm not hearing consensus to make this change now.

However, there does seem to be some agreement that if other breaking changes are made (for more substantial reason), this might be worth reconsidering.

As such, I'm closing but also flagging as "revisit-upon-change" so that we can do so in that case. That label is also being applied to the Hpack optimization issue.

Regards,



On 27 Sep 2014, at 2:02 am, Nottingham, Mark <[hidden email]> wrote:

> <https://github.com/http2/http2-spec/issues/603>
>
> It doesn’t seem like there is consensus to adopt a change here; as many have pointed out, our protocol is not aligned anyway, and the other gains are marginal at best.
>
> Anyone feel strongly about this still, or can we WONTFIX?
>
>
> --
> Mark Nottingham    [hidden email]   http://www.mnot.net/
>

--
Mark Nottingham    [hidden email]    https://www.mnot.net/





Reply | Threaded
Open this post in threaded view
|

Re: #603: Frame layout

Adrian Cole
In reply to this post by Simpson, Robby (GE Energy Management)
I'm pretty sure every draft I've worked on was incompatible with the
prior. It doesn't matter if the framing or hpack or flags or offsets
were at fault. It is no longer usable, so you adjust. I honestly don't
care if there's a change the framing, as any change means jumping back
in the code, adjusting tests, etc. None of this has been rocket
science code.

At the end of the day, if we do any change, we might as well include
all sensible changes. In other words, if this isn't the final draft
from an implementation pov, I don't mind adjusting on outcome of this
thread. No biggie.

That said, I understand I'm in the easiest position, a library author.
I have basically no deployment gravity to consider, and that most
aren't that lucky.

-A

On Mon, Sep 29, 2014 at 6:04 PM, Simpson, Robby (GE Energy Management)
<[hidden email]> wrote:

> I do not see these changes as aesthetic.  To me, having flags as part of the frame header when they are very much dependent on the frame type is problematic.  Flags in the frame header should be type-agnostic.  This then allows the individual frames (and extensions) to define flags however they may need them in their own payloads.  This also allows future type-agnostic flags to be defined (should we need them) without having to worry that flags have already been claimed by extensions.
>
> And then you get the aesthetics (and alignment) for free!  :-)
>
> From: Michaela LaVan <[hidden email]<mailto:[hidden email]>>
> Date: Monday, September 29, 2014 at 4:31 PM
> To: Daniel Stenberg <[hidden email]<mailto:[hidden email]>>
> Cc: Charles Simpson <[hidden email]<mailto:[hidden email]>>, Poul-Henning Kamp <[hidden email]<mailto:[hidden email]>>, "Nottingham, Mark" <[hidden email]<mailto:[hidden email]>>, HTTP Working Group <[hidden email]<mailto:[hidden email]>>
> Subject: Re: #603: Frame layout
>
> Came here to say something similar, but Daniel beat me to the punch.
>
> As an implementer I am strongly disinclined to make what are essentially aesthetic changes to the frame layout at this point.  Even seemingly minor changes in the most recent draft cost the working group weeks of interop data while we ironed out the bugs and got everyone on the same page. To me, the changes Roy is proposing are not worth the setbacks to our timeline that they would incur.
>
> Like everyone else here I believe in the potential of HTTP/2 and want it to succeed. Right now the biggest threat to our goal of widespread adoption is not frame header field order or byte misalignment. It's getting to the end of 2014 and not having a protocol to ship.
>
> On Mon, Sep 29, 2014 at 2:48 PM, Daniel Stenberg <[hidden email]<mailto:[hidden email]>> wrote:
> On Mon, 29 Sep 2014, Simpson, Robby (GE Energy Management) wrote:
>
> I'm implementing HTTP/2 because I believe it will be successful, widely used, efficient, and long-lasting.  At this stage, if there are changes that can be made to increase those qualities, I will _gladly_ update my implementation.
>
> If someone is implementing a draft, they should be willing to update that implementation until the standard is finalized.  Otherwise, they should wait to implement.
>
> I don't mind changing my (or others) code to adapt to changes in the protocol spec. I've been on this journey from the start and I'm one of those who have adapted code many times already and I have the feeling I will do more of that. I'm not afraid of changing code when it's necessary.
>
> I want a protocol to implement so I want the HTTP/2 spec to settle down, and therefore I object aginst nit-picking details that in my mind don't have any particular impact in the protocol's ability to succeeed and that aren't very important to make the protocol easier to implement. I just don't consider that minor polish worth the extra time, effort and interop work that will follow.
>
> But if there's any other actual - REAL - change that will go in that changes the format anyway, then I won't mind seeing these framing changes as well as then we've already broken the seal anyway and can just as well do that change too.
>
> --
>
>  / daniel.haxx.se<http://daniel.haxx.se>
>
>
>