[Standards] Proposed XMPP Extension: Entity Versioning
sam at samwhited.com
Wed Sep 2 05:15:02 UTC 2015
On Tue, Sep 1, 2015 at 11:34 PM, Lance Stout <lancestout at gmail.com> wrote:
> I do have some questions about Section 5.3 Aggregate Tokens.
> The spec describes its use with MUC rooms, but is providing versioning for disco#items to do it (which makes sense given that providing this sort of universal API is one of the stated goals for entity versioning).
> So, because this is versioning disco#items in addition to rosters, there are some things that need additional consideration when using aggregate tokens:
> - Items could have a JID with a resource, so not just bare JIDs.
> - Results might contain multiple items with the same JID, but different node values.
> - 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 hadn't thought about some of these particular use cases, but I had
thought about the fact we were likely to hit stumbling blocks if we
tried to apply this spec too broadly. I'm fond of quoting the mantra,
"one size fits all fits no one", and this may be a good case for that.
What about, if this protocol were to move forward, strictly defining
this in terms of roster queries and MUC disco, but noting that other
"profiles" or "implementations" might be made for caching other types
of list such as pubsub nodes, entity capabilities (the use case I'm
most interested in seeing after mucs/rosters), etc.?
Potentially it could have a registry, but half the registries I look
at on the registrars site don't appear to have anything beyond an
initial handful of things registered before XEP authors forgot that
the registry existed (eg. well known errors, which I was looking at a
moment ago), so maybe this isn't a good idea.
I'll try to address the technical side of this tomorrow (when it's not
quote so late my time) and make sure that the spec is robust at least
in the case of rosters / MUC disco.
> 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 should probably be clarified in the text, thanks for pointing that out.
> It was mentioned that there was a second piece to the versioning work HipChat has done to specify requesting/providing subsets, so these issues might already be solved in that portion, but I would like to see them addressed here.
It doesn't cover this use case, but I'll try to wrap up writing and
adding it to the spec shortly. I had intended to submit that as a
second XEP because the idea of a partial roster/other item sync (in
which the server decides to show you a limited view of your actual
roster and only update it as necessary) seemed like a separate
problem, however, Dave's comments made me realize that it probably
makes sense to put them all in one document.
More information about the Standards