[Standards-JIG] Re: Multiple Affiliation/Role Get Requests in One (JEP-0045)

Nolan Eakins 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
> somewhere?

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.

- Nolan

More information about the Standards mailing list