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:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
