Subject: Getting it out the door. Re: #578: Header Table and Static Table Indices Switched

From: Greg Wilkins <[email-masked]>
Date: Sun, 28 Sep 2014 12:23:44 +1000

On 28 September 2014 03:52, Mark Nottingham <[email-masked]> wrote:

> I think the time for that has truly past; most of our implementers want to
> get this out the door and running, not do another round of R&D.

Just for the record, as an implementer I want neither to just get it out
the door, nor to do another round of R&D.

I do not believe that the flaws in the protocol can be resolved by simply
iterating the process that we are in.    If there was interest in reviewing
the charter, collecting more public data to work against  and taking a step
back to truly reviewing what has been produced.... then I'd be all for that
regardless of the time it would take or the pie on our faces.

Failing that, I'm inclined to not change too much in the current draft -
but if good data is presented to indicate the value of minor changes (eg
switching dynamic/static table, adding values to static table entries,
huffman recoding etc etc.) then I'm happy to follow the data.... at least
for one more round.

regards

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Adrian Cole <[email-masked]>
Date: Sun, 28 Sep 2014 15:09:08 -0700

Agreed.

If we are talking trivial changes to implement like switching this
back or mucking with static table or huffman codes, I don't mind. They
are easy to knock out vs rearranging frames, op-codes, lengths, etc.

-A

On Sat, Sep 27, 2014 at 7:23 PM, Greg Wilkins <[email-masked]> wrote:
> Just for the record, as an implementer I want neither to just get it out the
> door, nor to do another round of R&D.
>
> Failing that, I'm inclined to not change too much in the current draft - but
> if good data is presented to indicate the value of minor changes (eg

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 29 Sep 2014 19:07:46 +1300

On 29/09/2014 11:09 a.m., Adrian Cole wrote:
> back or mucking with static table or huffman codes, I don't mind.
> They are easy to knock out vs rearranging frames, op-codes,
> lengths, etc.

Strange. I find quite the opposite.
 Re-arranging the order of a fixed sequence of struct members or
parser calls to fill them is far easier than implementing a whole
management mechanism to cope with static table ID changes every time a
header is parsed or scheduled to be written to a connection.

Amos

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 29 Sep 2014 15:59:48 -0700

> header is parsed or scheduled to be written to a connection.

A management mechanism? i.e. index = staticTableIndex + headerTable.length?