[Standards] mobile optimizations (was: Re: DevCon report)

[Dave Cridland]

On Wed Feb 27 20:56:28 2008, Fabio Forno wrote:
> On Wed, Feb 27, 2008 at 6:52 PM, Dave Cridland <dave at cridland.net>  
> 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:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade