[Standards] Proposed XMPP Extension: Entity Versioning

Dave Cridland 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...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150901/23bdb7e3/attachment.html>

More information about the Standards mailing list