W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Back to the drawing board? was: #540: "jumbo" frames

From: David Krauss <potswa@gmail.com>
Date: Thu, 26 Jun 2014 00:15:11 +0800
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <20411E76-5833-4EB0-B901-B678C2274343@gmail.com>
To: Greg Wilkins <gregw@intalio.com>

On 2014–06–25, at 6:36 PM, Greg Wilkins <gregw@intalio.com> wrote:

> On 25 June 2014 12:20, David Krauss <potswa@gmail.com> wrote:
> I’ve not been following this (my implementation is on hold as it seems HTTP/2 is going back to the drawing board) but any “jumbo frames” scheme should be amenable to hardware implementation.
> David,
> I encourage you to progress your HTTP/2 impl, as I certainly found that doing so has greatly improved my understanding of the draft and the issues associated with it.

I’m not quitting :) but at the moment, I don’t have as much to add to the group effort as I’m less far along, and it’s better to conservatively wait out any possible churn as my system is less amenable to rapid prototyping.

> While I think there are outstanding issues, I'm not sure that the continued discussion of them does mean that we will go back to the drawing board, nor that the WG thinks those issues are not adequately addressed.  The current draft is implementable and there does appear to be considerable interest in going forward with it to see how it goes. 

“Back to the drawing board” might have been a little strong, heh, I just meant the framing layer and the protocol-wide state machine that tracks header blocks are pretty fundamental.

> ie, whilst the current draft is not how I would do it if I were god,  I could live with most of it if it did become an RFC..... and would revel in the "I told you so" rights I would get when we are all back here in a few years

As a newbie, this group has always responded nicely to my ideas, even if I don’t have much “push.” Things currently seem to be going in a good direction. The immediate effort with headers and framing is for minimizing RAM and cycles per stream, and that’s the bread and butter of the whole operation.

> because it failed to be widely adopted or we have to work out how to deal with the growing usage of massive headers :)

Massive headers I find worrisome, only because they are already theoretically supported by HTTP/1 but implementations universally impose limitations. The existing practice needs more emphasis. But, this too seems to be getting addressed currently.

Received on Wednesday, 25 June 2014 16:15:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC