Re: Header compression question: duplicate header entry and current index on computing working set

[Roberto Peon <[e-mail]>]

Not necessarily-- If the encoder/compressor says that element 5 is k,v, and
then it also appends k,v as element 7, for example.

When this happens things are less efficient, yes, but that is it.

There has been little optimization around duplicate k,v entries because
1) It is very uncommon
2) It doesn't break anything
3) There doesn't seem to be a good reason to encourage the behavior by
optimizing for it.
-=R


On Wed, Jul 17, 2013 at 10:08 AM, Jeff Pinner <[e-mail]> wrote:

> Doesn't the decompressor have to sweep the table to create the new
> reference set and compare the (index, name, value) entries?
>
>
> On Wed, Jul 17, 2013 at 9:59 AM, Mike Bishop <[e-mail]
> > wrote:
>
>>  How did the object get into the reference set?  Because the compressor
>> referenced an object by index, or included it as a literal and added it to
>> the table.****
>>
>> ** **
>>
>> So the object in the reference set points to the entry in the table it
>> was added with.  If there happens to be another identical entry in the
>> table, nothing says that the decompressor will even notice that.  I don’t
>> recall anything that requires the decompressor to sweep the header table
>> looking for matches – that’s the compressor’s job.****
>>
>> ** **
>>
>> *From:* Tatsuhiro Tsujikawa [mailto:[e-mail]]
>> *Sent:* Wednesday, July 17, 2013 9:52 AM
>> *To:* Martin Thomson
>> *Cc:* [e-mail]
>> *Subject:* Re: Header compression question: duplicate header entry and
>> current index on computing working set****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> On Thu, Jul 18, 2013 at 1:36 AM, Martin Thomson <[e-mail]>
>> wrote:****
>>
>>  On 17 July 2013 08:56, Tatsuhiro Tsujikawa <[e-mail]>
>> wrote:
>> > In 3.4, to compute working set from reference set of headers, the index
>> of
>> > entry in header table is required.
>> > The question is, when the duplicate entries are in the header table,
>> which
>> > index is used as the index of working set?****
>>
>> If, for some strange reason, a compressor created multiple identical
>> entries in the table, the decompressor is required to respect that
>> choice, even if it is likely to be a bug.  This prevents the
>> decompressor and compressor from getting out of sync.
>>
>> The compressor can then reference any of the entries when using an index.
>> ****
>>
>>  ** **
>>
>> If the choice is arbitrary, then the compressor and decompressor may
>> choose different index and****
>>
>> can get out of sync.****
>>
>> ** **
>>
>> For example,****
>>
>> Current header table:****
>>
>> |0|name1|value1|****
>>
>> |1|name1|value1|****
>>
>> ** **
>>
>> If name1/value1 is in reference set, compressor chooses index 0, and
>> decompressor chooses index 1.****
>>
>> compressor wants to remove name1/value1, so reference index 0.****
>>
>> In decompressor side, however, seeing index header representation with
>> index 0 and it is not in its reference set****
>>
>> (because name1/value1 is index 1), retrieve index 0 from header table and
>> add it to working set.****
>>
>> Maybe I misunderstand the draft.****
>>
>> ** **
>>
>> If multiple identical entries are considered as a bug, then it would be
>> better to****
>>
>> prohibit it in the spec and we are happy to not to consider these things.
>> ****
>>
>> ** **
>>
>> Best regards,****
>>
>> ** **
>>
>> Tatsuhiro Tsujikawa****
>>
>> ** **
>>
>> ** **
>>
>
>