On Tue, Sep 1, 2015 at 11:34 PM, Lance Stout <lancest...@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. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
