Re: Header Compression - streaming proposal

The delta2 codec did have a requirement on doing toggles first.
It also had a mode which used 8-bit index sizes.

Both/all of these things have been played with already, and have had both
drafts and implementations, and one can feel free to look at both :)
-=R


On Thu, Jul 11, 2013 at 9:26 AM, RUELLAN Herve
<Herve.Ruellan@crf.canon.fr>wrote:

> I've been pondering on this proposal for some time.
>
> I think it has several impact on the header compression mechanism.
>
> 1. The decoder can be much simpler. In particular, it can help avoiding
> nasty bugs due to the working set shadowing the index table.
>
> 2. It makes the encoder more complex. It think that the current spec
> allows for an encoder doing only one pass on the headers to encode, with
> the removed headers encoded at the end.
> This new proposal enforce doing at least two pass on the headers to encode.
>
> 3. For performances, I will believe only when I see some numbers ;-).
> The count of indexed entries will usually cost 8 bits. But 1 bit will be
> reclaimed on each entry, allowing to encoding larger index values on the
> first byte of each entry. I'm inclined to think this will result in a net
> gain, but I don't know how much.
> However, if we decide to include typed codec, the reclaimed bit could be
> used as part of the signaling of which codec was used, and could decrease
> the cost of this inclusion.
>
> Hervé.
>
> > -----Original Message-----
> > From: Martin Thomson [mailto:martin.thomson@gmail.com]
> > Sent: mercredi 10 juillet 2013 18:48
> > To: Gábor Molnár
> > Cc: HTTP Working Group
> > Subject: Re: Header Compression - streaming proposal
> >
> > On 10 July 2013 00:53, Gábor Molnár <gabor.molnar@sch.bme.hu> wrote:
> > > I opened an issue on GitHub for this proposal with minor modification
> > > to the original text:
> > > https://github.com/http2/compression-spec/issues/11
> > >
> > > If I get more feedback, I will be happy to draft a PR as well.
> >
> > The only feedback I have is that you could reclaim a bit from each of the
> > existing opcodes by doing this, which could produce a pretty big
> increase in
> > performance.
> >
> > Starting the header block with a count (the number of index entries,
> prefix
> > size 0), could make this quite efficient.
>
>