On Tue Apr 14 09:41:28 2009, Jiří Zárevúcký wrote:
2009/4/14 Dave Cridland <d...@cridland.net>:
> On Mon Apr 13 18:18:39 2009, Jiří Zárevúcký wrote:
>>
>> Am I right?
>
> Yes, you are, well spotted.
>
Actually, I'm not. My reasoning would require that the items
themselves are partial, which they are not. So the push includes the
complete last known state of the item, not a change.
Ah, yes - your reasoning would alternately mean that a single change
could encompass more than one roster item, which it also cannot (and
if it could, the solution would be different).
I shouldn't reply to these things so late at night.
That means there is no such problem, as even though the client is
not
guaranteed to have a complete state on failure, it will have it when
it resumes receiving from the point it left of.
Yes. So we're both wrong - yay! But thanks for looking into this
carefully.
That also means this part can be somewhat misleading:
4. The interim roster pushes would not include all of the
intermediate steps, only the final
result of all changes applied while the client was in fact
offline.
.. as it suggests that the changes (to a single item) combine, while
in fact they replace each other.
I'm not sure they replace, as such - collapse might be a better word.
Changing both subscription state, and, later, changing name, results
in a single roster push containing both changes. However, changing
name twice will effectively replace.
I think an example speaks a thousand words, here - since you've a
feel for this, could you write one? (I'm sure Peter would appreciate
it).
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
