[Standards] mobile optimizations
dave at cridland.net
Thu Feb 28 09:50:17 UTC 2008
On Wed Feb 27 18:19:13 2008, Alexander Gnauck wrote:
> Dave Cridland wrote:
>> 2) Client says "I have the roster as of this point in time".
>> Server says "Here's all the changes since then.".
>> This is obviously the best option in terms of efficiency, but it,
>> too, has problems. The key issue is that roster entries won't die
>> - instead, they'll be maintained along with a timestamp when
>> deleted, in order that the server can tell a client it's gone.
> yes I think the logic on the server will get very complicated. Util
> I have a mutual subscription to a contact the server updates the
> roster item several times(subscription=none,from or to,both +ask).
> This will be ~5 versions until the subscription is mutual.
But that's fine. The server just stores a version number against each
entry - no need to remember what previous versions were. This is also
why remembering what got deleted is tricky, because you break that
>> I also have a fondness for modified strictly increasing
>> timestamps, but implementors need to appreciate that computer
>> clocks go backwards, so they need to remember to handle odd cases
>> like that by "letting time catch up" - just using a few ms later
>> than the last timestamp until the real time is greater than the
>> last timestamp.
> for this reason I would prefer a versioning of the roster, so I
> client can just tell the server I have version 235241 of the
> roster, let me know if this is the current roster or send me the
> changes otherwise.
As I said to Tony - just a fondness for modified strictly increasing
timestamps. I'd be happy with an otherwise meaningless strictly
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards