On Wed Feb 27 20:56:28 2008, Fabio Forno wrote:
On Wed, Feb 27, 2008 at 6:52 PM, Dave Cridland <[EMAIL PROTECTED]>
wrote:
> 3) Client says "I have the roster as of this point in time".
Server
> either says "Here's the changes" or "Here's the whole roster",
> depending on whether it can find all deletions.
>
> This is basically addressing the shortfall of the above, and
allows
> for a single RTT self-correcting error case. I like this one
best,
> and it's pretty easy to implement.
I like this one, since it always has a backup when no
sinchronization
is needed. Moreover the server can store only a window of changes,
and
send the whole roster if the last known by the client is too old
No, not too old, as such.
Let's call our strictly increasing sequence a modseq. Every time a
roster item gets pushed, the server includes the current value of the
modseq and increments the modseq. We'll call this the roster item's
modseq value.
Every time a roster item gets deleted, the server records the value
of the modseq at the last deletion, and increments the modseq. We'll
call this the roster's last-deleted modseq value. We need to tell the
client about this, too.
So the data overhead is now one integer per roster, plus one integer
per roster item - low overhead.
Now, when the client requests the roster, it supplies a last-known
modseq value. The server first checks the last-deleted modseq. If
last-known < last-deleted, then send the whole roster. Otherwise,
send roster items for which modseq > last-known.
And we're done. No need for remembering what the changes were, no
need to do insanely complicated things with diffs, versioning, etc.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
