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

That is true. That implementation would require substantial code additions,
though, moreso than the other options.
-=R


On Thu, Oct 17, 2013 at 11:49 AM, Mike Bishop
<Michael.Bishop@microsoft.com>wrote:

>  If you maintain the reference set into the static table as a bitmask,
> we’re talking about eight bytes per connection.****
>
> ** **
>
> *From:* Roberto Peon [mailto:grmocg@gmail.com]
> *Sent:* Thursday, October 17, 2013 11:47 AM
> *To:* Martin Thomson
> *Cc:* Jeff Pinner; RUELLAN Herve; Fred Akalin; Roberto Peon;
> ietf-http-wg@w3.org Group
>
> *Subject:* Re: I ran across this while working on the spec.****
>
> ** **
>
> I have (that was what Herve proposed :) ), but I do worry: A set typically
> ****
>
> requires two pointers per element, plus the size of the element itself plus
> ****
>
> pointer to the index itself.****
>
> If we call that 8+8+4 bytes of overhead per entry, we're talking about a
> kilobyte of potential overhead. That is noticable.****
>
> ** **
>
> -=R****
>
> ** **
>
> On Thu, Oct 17, 2013 at 11:43 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:****
>
> On 17 October 2013 11:17, Roberto Peon <grmocg@gmail.com> 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"?****
>
>  ** **
>