[Standards] Proposed XMPP Extension: Entity Versioning
sam at samwhited.com
Thu Sep 3 03:54:30 UTC 2015
On Wed, Sep 2, 2015 at 10:03 PM, Lance Stout <lancestout at gmail.com> wrote:
> There is this text about constructing the aggregate token:
> This aggregate token is calculated by constructing a string of
> comma separated "bare JID:version" pairs
Wow, yup... there it is... fixed in the PR.
> I don't think this will affect anything, but there is the odd item
> to note, which is that ',' is a valid character in the localpart of a
> JID. If you are depending on that as a separator for some reason, that
> might need to be adjusted.
The list formatting was just chosen arbitrarily since it doesn't
really matter. Having some separators probably makes reading error
logs easier (that's a bit of a stretch as far as added value is
concerned, but there's not really any down side to having the commas
>> I've added a statement to make it clear how this should be handled.
>> Since the actual value doesn't matter, we just sort as usual (and
>> since we're constructing the JID:version pairs before sorting, we just
>> end up sorting based on the version token).
> Does that mean we really don't even need to use JIDs in the source string
> for the aggregate token? Use a comma separated sorted list of version tokens?
I suppose it could; I think the idea in having both in the original
implementation was that we were using deterministic version tokens at
the time that were created from a digest of the various mutable
properties, and there was a high chance of collision. We scrapped that
in favor of the random tokens which are recommended in the
implementation notes, but the JID:version pairs remained. I'd prefer
to keep them just because we're already using them and I suspect that
it could lower the likelyhood of a false positive aggregate token
match due to low entropy version tokens (but yah, that's also a
stretch... probably doesn't matter either way.).
> Specifically, how would I request an aggregate token for the list that
> this disco query would return:
> <query xmlns="http://jabber.org/protocol/disco#items" node="archived-rooms" />
Ah, right. That's a great question, and one we don't have solved, I'll
ask Doug (the original author of our internal tech spec) what he
thinks tomorrow, but your solution looks reasonable.
It also might be more flexible to just change how this works and wrap
whatever the query you want an aggregate token hash for, eg:
(though that doesn't read very well... might have to think about how
it works, but you get the idea)
More information about the Standards