[Standards-JIG] proto-JEP: Proposed Stream Feature Improvements

[Dave Cridland]

On Sun Aug 13 23:33:15 2006, Joe Hildebrand wrote:
> Stream startup doesn't happen as often as other parts of the  
> protocol.  I suggest we optimize other things first.  For example, 
> it  would be great if there was a way to pick up an existing 
> session that  had gotten dropped, so that you didn't have to 
> re-retrieve your  roster, send/receive presence, and get offlines 
> just because you  changed cell towers.  That might make for a 
> *huge* savings for non- trivial roster sizes.

I sketched out something to deal with rosters, in particular, on the 
jdev list some time ago. To repeat that message, which was in 
relation to a JEP-150 based solution:

Remember, the typical case is going to be that nothing has changed. 
JEP-150 handles
this case reasonably well. The next most common occurance will be a 
single change
or addition, but JEP-150 doesn't handle this at all.

FWIW, ACAP and IMAP+CONDSTORE both have models we can copy here:

1) The roster has a magical strictly increasing number. I'll call 
this the roster modseq. Conceptually it's like a timestamp, except 
it's like a timestamp would be if timestamps worked. (ACAP uses 
timestamps adjusted to work, IMAP uses magic opaque 64-bit numbers. 
Same thing, really.)

2) With any change, deletion, or addition, this value is increased, 
and the roster entries added or changed get assigned the new value. 
These values need to be transmitted to the client as part of the 
roster entry.

3) Operations need to be provided for:
a) obtaining changes since a modseq
b) obtaining a list of deletions since a modseq (Deletion tracking 
can be hard, and tends toward infinite data retention, so this may 
error)
c) obtaining a list of entries without any detail. (This would  be 
used for client-side deletion detection. We'd be sending just the 
<item jid="foo at example.com"/> and no groups, names, etc.)
d) Obtaining just a count of entries. You'd probably combine this 
with (a), in practise.

Note that the server doesn't have to store the state of all clients, 
or anything drastic, it's just one extra integer per roster entry, 
plus whatever deleted roster entries it wants to keep.

Clients get to sync cheaply as a result. (Really clever handling may 
even reduce the resynch round-trips to zero, as IMAP CONDSTORE can.)

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