Hi,
On Feb 28, 2008, at 9:58 AM, Dave Cridland wrote:
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.
If you keep the deleted roster entries around for some time (server-
admin specified) you can prevent the full sync on delete scenario.
And we're done. No need for remembering what the changes were, no
need to do insanely complicated things with diffs, versioning, etc.
+1
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
