[Standards] Proposed XMPP Extension: Entity Versioning

Sam Whited sam at samwhited.com
Tue Sep 1 23:26:35 UTC 2015


On Tue, Sep 1, 2015 at 5:35 PM, Dave Cridland <dave at cridland.net> wrote:
> I think most (or all) of the above only applies if you have rosters that are
> computed on demand, rather than managed by users via clients.
>
> Otherwise all you need on a simple roster (no shared groups) is a counter
> for the version, the value of the latest tombstone *not* retained (ie, the
> last delete if there are no tombstones), and per item, the value of the last
> change, and if it's deleted (ie, if it's a tombstone). No multiple versions
> of anything. Tombstones are optional; but without them it means it's only
> efficient for adds.

That's all true for simple rosters, but our entire use case is shared
rosters / groups that are managed by the server, and we're certainly
not the only ones (every company I've ever worked at has used XMPP for
team communication, and they've all had shared rosters).

Further feedback from Doug (who's not on this list):

> I'd agree XEP-0237 is a better spec for smaller deployments, but it fails if you want to get efficient, differential updates for large deployments, because you're depending on timestamps or some other shared, monotonically increasing resource, which are hard/nearly impossible on large clusters
> this spec is all about trading upload for download for the benefit of server scalability
> in our case, it was also nice to get differential updates in place (which we could have achieved with a proper implementation of XEP-0237, but we would've taken on the server challenge of maintaining some kind of reliable, cluster-wide sequence generator)
> also, XEP-0237 always assumes we want the full roster or rooms collection. With our XEP, the server can selectively issue subsets to certain users pretty trivially
(also part of our scaling story)


(we know that timestamps are [rightfully] discouraged by XEP-0237, but
monotonically increasing version numbers still need to be synced)


> So you're saying you added a bunch of stuff for efficiency, and then had to
> add an efficient synch mechanism due to the inefficiency it caused? ;-)

I'm not sure I follow? All of this was added (or at least concieved)
as once piece to solve the problem. It was then broken into two
phases, the first phase would add caching to roster and disco#items
lists (using the mechanism described here) and the second phase would
add the ability to only download part of the list (and fetch the rest
only as it's needed).

> Amazingly, the simple mechanism I detailed above still works for items
> containing metadata, incidentally.

The metadata's not a show stopper, and I don't mean to suggest that
roster versioning doesn't handle metadata, I just use it as an example
because it means that we're downloading a lot more info (uploading
1000 small version tokens is a good trade off to stop downloading 999
large metadata blobs).

> As I said before, the difficulty is in
> dealing with multiple views; I think MUC room listing has those, and I don't
> have a solution - at least, not without a changelog.

This is a fairly good solution (once I fix the issue of deletes). This
is one of the use cases we're using it for right now (to version muc
room lists, which are more or less unique per user because private
rooms don't show up in the list unless you're in the ACL).

—Sam




-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com



More information about the Standards mailing list