[Standards] mobile optimizations

[Dave Cridland]

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  
simplicity.


>> 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  
increasing value.

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