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: [EMAIL PROTECTED]
Use XMPP!
