[jdev] Roster caching

[Peter Saint-Andre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Cridland wrote:
> On Thu May 04 10:40:17 2006, Vinod Panicker wrote:
>> On 5/4/06, Tijl Houtbeckers <thoutbeckers at splendo.com> wrote:
>>> http://www.jabber.org/jeps/jep-0150.html
>>
>> Thanks!  Seems like a perfect match.
>>
>>
> Hmmm... Well...
> 
> The trouble is, you're getting all or nothing - if you add a group to a
> single contact out of 150, then you're still getting everything. Added a
> single new contact? Get everything. Deleted one? Get everything.
> 
> 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 (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.)
> 
> 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 can
> even reduce the resynch round-trips to zero, as IMAP CONDSTORE can.)

We've never messed with rosters at all. Plenty of people would like to
do fun, even magical things with rosters (annotations and all the rest)
but the necessary changes have never been rolled into the core roster
functionality. The beautiful optimization you suggest here could be
offered by servers in a separate namespace so I don't have any strong
objections to it. I'm not sure how much demand there really is for this
feature, but server and client developers could experiment and see if it
makes life much better for all concerned. :-)

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEWnMPNF1RSzyt3NURAm9iAKCubFvEz90r2BP8bPUCWKv+BWOTRQCeI8+Y
OPGviQMZx55bdNhaTtw3V0E=
=q8/g
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20060504/44e29ed7/attachment-0002.bin>