[Standards] mobile optimizations

[Pedro Melo]

Hi,

On Feb 28, 2008, at 9:50 AM, Dave Cridland wrote:
> 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.

Just keep the roster entry around, marked as deleted.

The cost really depends on how common roster deletion is, really.

Also you can keep a minimum version at the roster level. If a client  
sends a version below that, force a full sync. This way, you can,  
from time to time, clear old deleted entries, and increase the  
minimum version the MIN(version_id) of the resulting roster.


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

I think the "always increasing" part is the most important feature.  
The rest can be left to the server authors.

Best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org
Use XMPP!