Hi, > Could you elaborate a bit on the use case and the need for it? I'm not > saying it's bad or irrelevant, but XEP-0045 was not designed to solve > every possible problem related to groupchat.
A user creates a (members-only) room and adds X contacts from his roster as member and invites them. Then the invitee receives the invitation and wants to know "who is part of the room" without the need to join the room. Because an invitee might want to decline an invitation if he thinks "oh, user XY is also in the room... no, then I don't want to join". This is the requirement of my boss/product owner, not mine :-). I need this "membership"-thing because a member/occupant shall see, who COULD be in the room, even if a member is offline. It's similar to Skype's group chat functionality if you are familiar with it. So, if I join a room I want to see all members/owners, even if they are offline. This works already with the current spec (7.11 Getting the Member List) The problem is, that 7.11 is restricted to occupants. I understand "occupants" as those who are currently online and IN the room. And "6.5 Querying for Room Items" only covers the case for occupants, so the disco query doesn't return members (which might be offline). It even says: "this means that they cannot possess 'affiliation' or 'role' attributes, for example." @top-posting: Sorry, my webmail interface (GMX) does not allow for those ">" quotes (afaik). I did it manually now. Christian Gesendet: Mittwoch, 05. März 2014 um 11:35 Uhr Von: "Peter Saint-Andre" <stpe...@stpeter.im> An: "XMPP Standards" <standards@xmpp.org> Betreff: Re: [Standards] XEP-0045 to Final? :) A: Because it messes up the order in which people normally read text. Q: Why is top-posting so bad? A: Top-posting. Q: What is the most annoying behavior on email discussion lists? On 3/5/14, 10:16 AM, Christian Schudt wrote: > Hi, > > could you elaborate on this proposal a little bit, please? Could you elaborate a bit on the use case and the need for it? I'm not saying it's bad or irrelevant, but XEP-0045 was not designed to solve every possible problem related to groupchat. > The room creator/owner publishes a node to a pubsub service, which contains > all room members and each invitee subscribes to this node (which is equal to > the room JID?)? > > What about the case, when a member invites further members? He would have to > modify to original node. I imagine that would be cumbersome to develop, when > you have to sync MUC affiliations and PubSub affiliations (on top of the > already complex pubsub management). > > It would be so much easier to just allow 7.11 Getting the Memberlist also for > the Entity Use Cases, so that an entity could just query a room for it's > members (without having joined the room): > > <iq from='cro...@shakespeare.lit/desktop' > id='member3' > to='co...@chat.shakespeare.lit' > type='get'> > <query xmlns='http://jabber.org/protocol/muc#admin'> > <item affiliation='member'/> > </query> > </iq> > > Maybe return a stanza error, if the requester is no member of the room. That's what I would suggest. Since that solves the problem, I'm wondering why you asked the question. :-) That is, is there some aspect of the problem that http://xmpp.org/extensions/xep-0045.html#disco-roomitems does not solve? (Section 7.11 is about occupants who are already in the room.) Peter > > Christian > > > Gesendet: Mittwoch, 05. März 2014 um 10:54 Uhr > Von: "Winfried Tilanus" <winfr...@tilanus.com> > An: standards@xmpp.org > Betreff: Re: [Standards] XEP-0045 to Final? > On 01-03-14 18:04, Christian Schudt wrote: > > Hi, > >> I recently was confronted with the following requirement: Create a >> (non-public members-only) room, grant membership to X contacts and >> send an invitation to these X contacts. >> >> Then after receiving the invitation, but BEFORE joining the room, the >> invitee should discover the members in the room and decide (based on >> this information) if he wants to join the room or if he should >> decline the invitation. > > You may consider to use pubsub in cases like these. > > Winfried >
