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 <mlavan@google.com> 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 <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
> 
> 

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

Received on Monday, 29 September 2014 21:57:10 UTC