Re: More header compression comments

2013/8/27 Martin Thomson <martin.thomson@gmail.com>:
> I've been going through this, and it occurred that most cases for
> header indexing use an arrangement where a 0 value indicates a
> literal, and 1+ is an index.
>
> [a] So, why not start header table indexing at 1 and save the confusion.

This is exactly what came to my mind when reading the latest draft.
AFAIK, the initial chromium header compression implementation had a
bug related to this confusion.

> [b] There's only one place where 0-based indexing is used, and that is
> for index toggling.  I have a suggestion for that too.
>
> Rather than have an opcode for the reference set toggling, simply
> start the encoding of a header block with a 0-terminated list of
> header table indexes to toggle.  Then you can reclaim a bit from the
> front of the other opcodes.

This would be in conflict with one of the main advantages of the
current design: it would require a two-pass encoder, so it would
require the encoder (or other parts of the stack) to store the whole
header set in the memory. Currently, the the decoder AND the encoder
can be be implemented in a (one-pass) streaming way, which is
something I think is important (and a great achievement)!

> [c] If you want to get crazy and are comfortable with requiring strict
> ordering, you can reduce the need for two-byte references by having
> each item in the list be a delta from the previous item.
>
> Thus, where you want to toggle the first, twenty-third and 120th
> entries, you would start the header block with: 1, 22, 97, 0.
>
> Of course, this is probably not that useful if you don't think that
> there is any value in having a large number of entries in the header
> table.
>
> --Martin
>

Received on Thursday, 5 September 2013 09:56:50 UTC