RE: I ran across this while working on the spec.

I think my preference goes for #0: do nothing, followed by #2. 

#2 is nice to have if you want to be able to just cleanup the compression context without reducing the max size to 0: the message is much more explicit about the intent.

Hervé.

> -----Original Message-----
> From: Fred Akalin [mailto:akalin@google.com]
> Sent: jeudi 17 octobre 2013 22:47
> To: Abdelaziz Raji
> Cc: Martin Thomson; Roberto Peon; Jeff Pinner; RUELLAN Herve; Roberto
> Peon; ietf-http-wg@w3.org Group
> Subject: Re: I ran across this while working on the spec.
> 
> On Thu, Oct 17, 2013 at 1:06 PM, Abdelaziz Raji <abdelaziz.raji@gmail.com>
> wrote:
> 
> 
>  e3eeeeeeeeeeeeeeèr
> 
> 
> 
> Cool story, bro.
> 
> I still like #1, shortly followed by #2, and I dislike the rest pretty much equally.
> 
> #1 still seems the most clean to me conceptually, as it follows from the fact
> that the static table entries take up no memory (although they still have the
> overhead of the reference set membership) and they're not evictable. In
> fact for consistency I'd prefer the calculated size of a static table entry to be
> 32 (i.e., the "normal" size minus size(name) + size(value)). This would
> account for any additional state other than the reference set membership
> (e.g., how many times a static table entry was explicitly emitted, etc.).
> 
> #2 has the advantage that it's explicit -- if clearing the context will be a
> common operation compared to sizing the context to some non-zero size,
> then perhaps we should just have an explicit operation for it instead of going
> through contortions to try and make it possible implicitly. I dislike it only
> because we probably *do* want to keep track of the overhead of the static
> table entries.

Received on Friday, 18 October 2013 16:12:59 UTC