[Standards] Proposed XMPP Extension: Entity Versioning

Sam Whited sam at samwhited.com
Thu Sep 3 01:06:23 UTC 2015


I've updated the PR to include some of Lances feedback.

On Tue, Sep 1, 2015 at 11:34 PM, Lance Stout <lancestout at gmail.com> wrote:
> - Items could have a JID with a resource, so not just bare JIDs.

This should be fine, I don't think I specified that it must use a bare
JID anywhere, but I may try to find an example later that uses a full
JID with resource part just to make it clear. I didn't throw it in
with this round of edits though.

> - Results might contain multiple items with the same JID, but different node values.

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).

> - Queries can specify a node
>
> These concerns can still apply to MUC services, because a MUC host could include any of the above forms in its disco#items responses (even with no node specified). For example, I've worked with MUC domains that also provided PubSub, so the disco#items results included a mixture of PubSub nodes and MUC rooms.

I've partially addressed this to say that the server should calculate
aggregate tokens based on whatever list it returns (if it's a mix of
items, it should return an aggregate token calculated from all of the
MUC rooms and pubsub nodes).


> The mechanism for requesting the aggregate token only accepts a namespace as input (or at least that is what I gathered from the examples, the text doesn't explain the relationship here). This is workable for rosters, but starts having issues with disco#items because we would also need to specify the queried node. Using this beyond disco#items could face additional challenges where there might be multiple request types under the same namespace but with different element names.

Unless I'm misunderstanding, this is already handled. You should be
querying the same node for the aggregate token list (eg. if you're
querying for a list of rooms, you query the MUC component or server,
if you're querying for pubsub items, you might query the MUC component
if it also provides pubsub, or you might query a separate entity which
provides pubsub for that server. Wherever you would send a pubsub
request would be where you'd query for a pubsub aggregate token).

Since aggregate tokens are optional (and fallback behavior is
specified) it doesn't matter if you hvae a server where the main
server supports aggregate tokens for roster items but the MUC
component (which might be a different system all together) doesn't
understand aggregate token queries.

The next step after these changes are merged is a slight refactoring
that breaks down the explanation of how this works into separate
sections for MUC and rosters, I think. Then we will define those as
"profiles" of entity versioning, and specify that future XEPs should
describe the behavior for other things (eg. pubsub nodes, HipChat
emoticon lists, entity caps, etc.).

However, I'd like to get these initial changes merged first to make
the changes more digestable for reviewing (large PRs are no fun for
anyone).

Thanks again for the feedback!

—Sam



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



More information about the Standards mailing list