Subject: Re: I ran across this while working on the spec.

From: Abdelaziz Raji <[email-masked]>
Date: Thu, 17 Oct 2013 13:06:23 -0700

e3eeeeeeeeeeeeeeèr

Sent from my MOTOROLA ATRIX™ HD on AT&T

Martin Thomson <[email-masked]> wrote:

On 17 October 2013 11:17, Roberto Peon <[email-masked]> wrote:
> Lets call this #6.

For #6, I think that you want to allow indexed representations to use
the static set, otherwise you don't get to take advantage of the
values there, just the keys.  You might say, however, that indexing
these doesn't add them to the reference set.

I really don't have a particular preference here, but I do note that
there is a strict upper bound on the size of the reference set after
evicting all dynamic entries.  That is, it's the size of your
reference, times the size of the static table.  Have you considered
the "don't worry"?

---

From: Fred Akalin <[email-masked]>
Date: Thu, 17 Oct 2013 13:46:36 -0700

> 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.

---

From: RUELLAN Herve <[email-masked]>
Date: Fri, 18 Oct 2013 16:12:29 +0000

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:[email-masked]]
> Sent: jeudi 17 octobre 2013 22:47
> To: Abdelaziz Raji
> Cc: Martin Thomson; Roberto Peon; Jeff Pinner; RUELLAN Herve; Roberto
> Peon; [email-masked] Group
> Subject: Re: I ran across this while working on the spec.
> 
> 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.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Oct 2013 09:57:49 -0700

> #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.

One of the arguments against the HEADERS frame flag you proposed was
that this increases the ways that header compression receives inputs.
Status quo is nice because only header blocks get passed to the
compressor.