[Standards] Some questions on MUC / XEP-0045

Dave Cridland dave at cridland.net
Fri May 16 08:52:18 UTC 2014


On 16 May 2014 06:43, Christian Schudt <christian.schudt at gmx.de> wrote:

>
> > 2. Is the <actor/> actually needed in the muc#admin namespace? There are
> no examples, but it's in the XML schema.
> >
> >
> > Yes, see http://xmpp.org/extensions/xep-0045.html#example-90
>
> Example 90 is in the #user namespace.
>
>
Ah, yes, you're quite right - I can't find any use for <actor/> within the
admin namespace at all.


> >
> > 3. Can a client request multiple affiliations and get all affiliated
> users? Like:
> >
> > <query xmlns="http://jabber.org/protocol/muc#admin">
> > <item affiliation="member"/>
> > <item affiliation="owner"/>
> > <item affiliation="admin"/>
> > </query>
> >
> > Which would return all members.
> >
> >
> > It's not against the schema, of course, but I think that's there for
> multiple modifications - something I actually think is a bad idea. I don't
> see any support for it in the text, though.
>
> Actually I think, this would be fine and it also feels natural to do.
> Modifying owner/admin/member list is all the same and one could modify
> affiliations of all users in one run.
> If a client sends an updated affiliations list to the server, the server
> should not care about the users' previous affiliations anyway. So it
> doesn't know/care if the client wanted to update (previous) owners, admins
> oder members only.
>
>
The problem is that a single <iq/> has atomicity guarantees, and a client
can achieve much the same thing (without the atomicity) by just sending
multiple <iq/>s at once. The difference is very slight to the client, but
makes a huge difference at the server end.

On reading, it doesn't make much difference, but unless it works everywhere
there's no advantage either.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140516/742de5c6/attachment.html>


More information about the Standards mailing list