On Fri, Aug 03, 2007 at 10:13:20AM +0200, Tomasz Sterna wrote: > I was talking with Grégoire Menuel (mu-conference developer) about > implementing Peter's idea of MUC rooms as items on the roster. > > Basically the idea is to teach MUC component to answer to subscription > requests. > So when you add [EMAIL PROTECTED]/nick to the roster and send the > subscribe request, MUC server replies subscribed+subscribe to you. When > you accept, you have a room on the roster with subscription "both". Next > time you broadcast your presence, you automatically join the room.
Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html ? That would still be useful to store non-autmatically-joined MUCs I guess? Also that XEP offers also a way to auto-join MUCs. > There is a problem on the client side though. > How would client know, that the presence from [EMAIL PROTECTED]/* are from > room participants, not from many resources of [EMAIL PROTECTED] user (not > on roster, thus ignored). That works (see below) but there is a more pressing problem here: Example 17. Jabber User Seeks to Enter a Room (Multi-User Chat) <presence from='[EMAIL PROTECTED]/pda' to='[EMAIL PROTECTED]/thirdwitch'> <x xmlns='http://jabber.org/protocol/muc'/> </presence> How does the client or the server know that he has to include such an <x xmlns='http://jabber.org/protocol/muc'/> element in the presence? If the client does send it's initial presence it of course won't include that element. So either the client sends directed presence or the server knows somehow what [EMAIL PROTECTED] is, so it can include the <x> element. Exploiting the fact that presences without <x> also work for joining a MUC would at least break this SHOULD in XEP-0045: MUC clients SHOULD signal their ability to speak the MUC protocol by including in the initial presence stanza an empty <x/> element qualified by the Also there is this issue: Before attempting to enter the room, a MUC-compliant client SHOULD first discover its reserved room nickname (if any) by following the protocol defined in the Discovering Reserved Room Nickname section of this document. The client has to do that before sending initial presence, right? If those issues, and some I don't know yet, are cleared up the client can easily recognize the presences from occupants by the <x> element: Usually a participant presence looks like this: <presence from='[EMAIL PROTECTED]/thirdwitch' to='[EMAIL PROTECTED]/laptop'> <x xmlns='http://jabber.org/protocol/muc#user'> <item affiliation='member' role='participant'/> </x> </presence> Or the update looks like: <presence from='[EMAIL PROTECTED]/secondwitch' to='[EMAIL PROTECTED]/desktop'> <show>xa</show> <status>gone where the goblins go</status> <x xmlns='http://jabber.org/protocol/muc#user'> <item affiliation='admin' jid='[EMAIL PROTECTED]/laptop' role='moderator'/> </x> </presence> With the <x xmlns="...muc#user"> element the client can figure out that this is a presence that comes from a MUC. Robin
