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.
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.
Regards,
Alex
