RE: All changes but huffman encoding integrated + a question

I think that #1 is a smart implementation of add then evict.

I agree that a naïve implementation of add then evict could consume 2x the max size. I think that a smart implementation can avoid this.

Hervé.

> -----Original Message-----
> From: Roberto Peon [mailto:grmocg@gmail.com]
> Sent: jeudi 17 octobre 2013 19:59
> To: RUELLAN Herve
> Cc: HTTP Working Group
> Subject: Re: All changes but huffman encoding integrated + a question
> 
> Add-then-evict generally implies that the amount of memory consumed is
> potentially 2X the stated max size.
> The proposed #1 boils down more to Evict or Move, then Add -=R
> 
> 
> On Thu, Oct 17, 2013 at 7:43 AM, RUELLAN Herve
> <Herve.Ruellan@crf.canon.fr> wrote:
> 
> 
> 	I think that these two resolutions are linked to the order in which
> eviction and addition occurs.
> 
> 	In 1), we add, then evict.
> 
> 	In 2), we evict, then add.
> 
> 	The current spec states 2), without a clearly specifying what an index
> for the header name means when there is an eviction.
> 
> 	1) may be slightly easier for the encoder, but is slightly more complex
> for a decoder.
> 	1) would also make the spec slightly easier to read.
> 
> 	I've no strong opinion one way or another.
> 
> 	Hervé.
> 
> 
> 	> -----Original Message-----
> 	> From: Roberto Peon [mailto:grmocg@gmail.com]
> 	> Sent: mercredi 16 octobre 2013 04:25
> 	> To: HTTP Working Group
> 	> Subject: All changes but huffman encoding integrated + a question
> 	>
> 	> Just wanted to let people know that the github version of the
> compression
> 	> spec includes all issues but huffman encoding (Herve and Jeff--
> thanks)!
> 	>
> 	> I believe there is a potential ambiguity though, which I'm not sure if
> people
> 	> realize or care about (and so asking here before potentially
> throwing mud in
> 	> clear water)...
> 	>
> 	> When adding a new header to the header table, one must first
> evict entries.
> 	> When using the indexed-name literal header representation, it is
> possible
> 	> that one may be evicting the entry that contains the name which
> the new
> 	> addition would need (and which needed to be examined in order
> to
> 	> determine the amount of space to free up in the first place).
> 	>
> 	> There are two obvious resolutions:
> 	> 1) Require that the name be kept in these circumstances (possibly
> by copying
> 	> somewhere (ideally into the end of the buffer)). If the storage for
> the
> 	> header table was a ring buffer, one would simply increment the '0'
> index
> 	> without copying.
> 	> This is my preference.
> 	>
> 	> 2) Make this illegal; This makes the encoder more complex as the
> encoder
> 	> must attempt to do this encoding and then check to see if actually
> fit every
> 	> time it does this kind of header representation.
> 	>
> 	>
> 	> What do people think?
> 	>
> 	> -=R
> 
>

Received on Friday, 18 October 2013 11:02:48 UTC