- From: Michaela LaVan <mlavan@google.com>
- Date: Mon, 29 Sep 2014 16:31:43 -0400
- To: Daniel Stenberg <daniel@haxx.se>
- Cc: "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "Nottingham, Mark" <mnotting@akamai.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAN9NB6T28X9NqJD43tt695czbJD8Kq-rQ+POKL1p+ixde=zArQ@mail.gmail.com>
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 <daniel@haxx.se> 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 > >
Received on Monday, 29 September 2014 20:32:11 UTC