RE: Header Serialization Discussion



> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: lundi 15 avril 2013 17:55
> To: RUELLAN Herve
> Cc: ietf-http-wg@w3.org
> Subject: Re: Header Serialization Discussion
>
> [snip]
>
> > My main concern with your proposal is about doing the LRU on both the
> encoder and the decoder.
> > I'd really like to keep the decoder as simple as possible, and so keeping all
> the buffer management on the encoder side is a real win for me.
> > In addition, the asymmetry means that the encoder is free to do whatever
> buffer management it wants. LRU is a very good default buffer management
> scheme, however I think there are cases where some clever scheme could
> beat it.
> 
> Well, it's not so much an LRU cache as a "least recently written"
> queue. The buffer essentially consists of 128 memory slots. These are
> assigned in order and rotate, with used slots deallocated and reassigned as
> the buffer fills past it's limit. The encoder, then, needs to be selective about
> just what it decides to assign to the buffer. So long as an implementation
> follows the proper assignment order, the specific implementation does not
> matter.
> 

I'm afraid that using a "least recently written" queue would have a bad impact on compaction performances. There are some headers that don't change over a whole session (e.g. the user agent), or only take a few values over the whole session (e.g. accept). With a rotating scheme, these headers would have to be periodically re-added to the buffer.

Hervé.

Received on Tuesday, 16 April 2013 16:07:24 UTC