[Standards-JIG] Re: Multiple Affiliation/Role Get Requests in One (JEP-0045)
sneakin at semanticgap.com
Fri Dec 10 18:01:37 UTC 2004
JD Conley <jconley <at> winfessor.com> writes:
> Both of these scenarios seem perfectly legitimate to me. I haven't
> tested it, but I doubt any of the existing services will actually deal
> with this scenario. Any thoughts? Should we note these use cases
I would be in favor of doing what your examples suggest. For Psi's MUC support
I'm planning on having role and affiliation editors. Each would have a tree
showing all the JIDs and their roles/affils that can be changed. By allowing
the protocol to allow your examples I would be saved from having to send
multiple requests to get lists for each role/affil. I also assume that setting
the changes would be condensed similarly too.
If you're looking for use cases, I would get rid of each use case for
requesting lists. I would condense them into "Edit Roles" and "Edit
Affiliations". You may not even need to specify individual roles or
affiliations in the request for items. Setting each list would have the same
semantics as the current use cases, ie: only sending the delta back.
One drawback would be that the received list of items could be large. Overall
the JEP would probably be simpler since 6 use cases would be condensed into 2:
edit roles and edit affiliations. I'm not sure how handling changes to JIDs
that you can't change would be handled. Maybe a simple ignore would work.
More information about the Standards