Re: delta encoding and state management

On Thu, Jan 17, 2013 at 9:49 AM, Nico Williams <nico@cryptonector.com>wrote:

> On Thu, Jan 17, 2013 at 11:21 AM, James M Snell <jasnell@gmail.com> wrote:
> > My main concerns with this approach are (a) even tho the decoder gets to
> set
> > limits on the amount of state used, keeping that state around is still
> > relatively expensive compared to what we have now, and (b) keeping it in
> > sync with the client, server and any number of intermediaries along the
> path
> > is likely going to prove difficult at best. We need to make sure we have
> a
> > good understanding of the worst case scenario with this approach (i.e.
> > nothing stored in context anywhere along the path).
>
> If the compression is hop-by-hop then there's no synchronization
> issues.  But then middleboxes may have to decompress and always
> re-compress (even if the headers are left unmodified) in each
> direction.
>
>
That's the exact problem I'm having really. Middleboxes will be required to
maintain a complete compression state (for requests and responses) as
opposed to just passing things through. Maintaining that state could become
quite expensive. If we don't maintain it, tho, the potential sync issues
become too messy.


> In general I'd much rather not have connection-oriented state at all,
> not even if it were transparent to HTTP.
>
>
Agreed, not sure how to avoid it and still get good compression (outside of
simply optimizing the encoding of values as much as possible... i.e. bohe)

- James


> Nico
> --
>