Re: delta encoding and state management

Correct. :)
-=R


On Thu, Jan 17, 2013 at 11:59 AM, James M Snell <jasnell@gmail.com> wrote:

>
> On Thu, Jan 17, 2013 at 9:56 AM, James M Snell <jasnell@gmail.com> wrote:
>
>>
>> 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.
>>
>
> Correction on this (the bits thankfully just kind of snapped together in
> my brain finally)... a middlebox would have separate decompression and
> compression contexts for each request and response and would translate
> between the two. If it receives a kvsto, it can choose not to store
> anything and pass those along as kvsto or eref, getting by without storing
> any of the actual values, but still having to maintain some amount of state
> for the translation to occur. So that part (finally) clicked in my head
> correctly but we still need to make sure we have a solid sense of just how
> expensive maintaining that context is going to be (best and worst cases).
>
> - James
>
>
>>
>>
>>> 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
>>> --
>>>
>>
>>
>