Re: [Standards] Some questions on MUC / XEP-0045
On Fri, May 16, 2014 at 6:43 AM, Christian Schudt christian.sch...@gmx.de wrote: 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. I don't see anything in the text that suggests this is possible, which pretty much means that it's fine for a server to support the query, but not for a client to actually make it without some further, undefined, negotiation. /K
Re: [Standards] Some questions on MUC / XEP-0045
On 16 May 2014 06:43, Christian Schudt christian.sch...@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.
Re: [Standards] Some questions on MUC / XEP-0045
On 14 May 2014 21:53, Christian Schudt christian.sch...@gmx.de wrote: Hi, I have some questions on MUC: 1. Shouldn't the (initial) room subject message have Delayed Delivery, because the subject was set some time ago? It probably should, but the spec doesn't mention anything about it (7.2.16 Room Subject). The room subject is a property of the room, rather than an event like a traditional message. It might even be sent from the room's own jid, rather than the occupant jid. I think most implementations treat it semantically as ongoing state rather than a message, but I don't think a delay element is wrong. I'd be curious to see what clients would do with it, though, before recommending it. 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 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. You can, of course, just send three iq/'s pipelined; it'll give you the same number of round-trip waits. 4. muc#roomconfig_whois config option: Is it used for roles or affiliations or both? The description says affiliations, but the sample includes moderators, which is a role. Can an implementation freely choose the possible options? I think it has to be roles, really - that is, the use of Affiliations in the registry submission is an error. This generally controls whether real jids are included in presence. Thanks for answer. -- Christian
Re: [Standards] Some questions on MUC / XEP-0045
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. 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. -- Christian
[Standards] Some questions on MUC / XEP-0045
Hi, I have some questions on MUC: 1. Shouldn't the (initial) room subject message have Delayed Delivery, because the subject was set some time ago? It probably should, but the spec doesn't mention anything about it (7.2.16 Room Subject). 2. Is the actor/ actually needed in the muc#admin namespace? There are no examples, but it's in the XML schema. 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. 4. muc#roomconfig_whois config option: Is it used for roles or affiliations or both? The description says affiliations, but the sample includes moderators, which is a role. Can an implementation freely choose the possible options? Thanks for answer. -- Christian
