[Standards] Proposed XMPP Extension: Entity Versioning
dave at cridland.net
Tue Sep 1 19:35:37 UTC 2015
So I think that as far as rosters go, this is duplicating XEP-0237 in a
considerably less efficient form.
XEP-0237§4 gives a fairly intense trip down implementation options, and
none of them require multiple versions of the roster as claimed by this
ProtoXEP. I have a personal preference for §4.3, though it gets complex
with shared groups and so on. Nevertheless, it is possible to get perfect
efficiency if you're willing to store tombstones.
Rosters are a particularly simple case for synchronization, because there
is a single view; disco#items has potentially one view per user, and as
such is more complex.
In particular, assuming a room has configuration A, and then changes to
configuration A' - while we can tell if A' is visible to a user U -- let's
call this V(A',U) -- we cannot tell if V(A,U) == V(A',U) without having A;
and given we don't always know which older configuration needs to be stored
to make that comparison, things can get complex fast.
As such, a '237 style approach would probably be limited in practise to
having a §4.2 approach of hashing the entire list.
This ProtoXEP tackles this problem by having the client upload its view for
comparison, although it also includes an exact-match mechanism.
However, it's not clear from the specification how a server can signal
removal (or lack of visibility), nor what advantages a client has in
exchanging the download of a large amount of data with the upload of a
large amount of data.
In short, I think I need a bit more convincing that this represents a
significant advantage over the XEP-0237 approach.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards