W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

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

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Fri, 18 Oct 2013 16:12:29 +0000
To: Fred Akalin <akalin@google.com>
CC: Martin Thomson <martin.thomson@gmail.com>, Roberto Peon <grmocg@gmail.com>, Jeff Pinner <jpinner@twitter.com>, Roberto Peon <fenix@google.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E52F50EE7E@ADELE.crf.canon.fr>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC