Hi there, On Tue, Feb 11, 2003 at 06:40:23PM +0100, Mats Bengtsson wrote: > > > > > 1): > > > > > > In creating a room I get: > > > jlib0 muc create [EMAIL PROTECTED] mats callback > > > SEND: <presence id='1007' to='[EMAIL PROTECTED]/mats'> > > > <x xmlns='http://jabber.org/protocol/muc'/></presence> > > > RECV: <message type='groupchat' to='xxx@localhost/coccinella' >from='[EMAIL PROTECTED]'> > > > <body>This room supports the MUC protocol.</body></message> > > > <presence id='1007' to='xxx@localhost/coccinella' >from='[EMAIL PROTECTED]/mats'> > > > <x xmlns='http://jabber.org/protocol/muc#user'> > > > <item jid='xxx@localhost/coccinella' affiliation='owner' >role='moderator'/></x> > > > <created xmlns='http://jabber.org/protocol/muc#owner'/></presence> > > > > > > I get a welcome message before confirmation that the room has been created. > > > Shouldn't the order be reversed? > > > > > The presence packet at the end signifies that you are now able to > > communicate in the room. The sequence goes as follows: other users > > presence, room messages, your presence. > > Yes, that I understand as well, but still, I get a message from a room a am creating > before confirmation that it is actually created. That is not logic! > Well, it depends on how you view presence - I'm going to re-read the jep carefully and will email the list again as soon as I decide how to interpret the information.
> > > 2): > > > > > > The browse component doesn't push the newly created room, as I think it should. > > > If I "manually" browse the muc the room shows up as expected, however. > > > > > I'm not sure what you mean by 'pushing'? > > The browse component sends out a jabber:iq:browse package without the > client requesting it. That happens here and there already. (can't remember the actual > situation right now) I think when you enter a room using jabber:iq:conference > you get > a push from the browse component. > The problem is that connection via jabber:iq:conference was never accepted as a protocol. I mean, who would you push the packet to? groupchat and muc both rely on the client requesting the information from the server. > > > > 3): > > > > > > The servers browse component seems to use a hex string as a resource where > > > it should use my nickname. Seems to be something from the jabber:iq:conference > > > component. When exiting the room, the presence package has the correct /nickname > > > resource. Very confusing. > > > > > > SEND: <iq type='get' id='1011' to='[EMAIL PROTECTED]'><query >xmlns='jabber:iq:browse'/></iq> > > > RECV: <iq type='result' id='1011' to='xxx@localhost/coccinella' >from='[EMAIL PROTECTED]'> > > > <conference xmlns='jabber:iq:browse' name='girls' type='public'> > > > <ns>http://jabber.org/protocol/muc</ns> > > > <user name='mats' >jid='[EMAIL PROTECTED]/13c6a01dc31309e331c2b018640b9c03b8534327'/></conference></iq> > > > > > The hex string is actually a SHA1 hash of the users real jid. Its used > > to reference a user, but not reveal the true jid. If the room is set up > > to allow people to see the real jid, then just browse > > [EMAIL PROTECTED]/13c6a01dc31309e331c2b018640b9c03b8534327 and > > it will show you the true jid. This also helps to keep compatability to > > existing clients that are used to this form with the > > groupchat/conferencing module. The real jid is used as the reference, as > > a person can keep changing their nick throughout a session, but they > > can't change their real jid > > Yes, I know, but that's how the jabber:iq:conference handles things. > I can't see from reading the MUC JEP that this is the case with MUC. > From the JEP, as far as I can read, it handles the /resource as the gc-1.0 > groupchat does, using /nickname. The MUC implementation and the JEP are not > consistent here. > It is certainly not consistent when you exit the room and see the /nickname from > presence. > The basic groupchat protocol also has no provision for browse. As per another mail I have sent, i've reworked browse so that initially you get the nick, and the conference jid for the user (room@service/nick). If you browse room@service/nick, you will either get the real jid, or the SHA hash version, depending on whether you are allowed to see real jids. > > > SEND: <presence to='[EMAIL PROTECTED]' type='unavailable'/> > > > RECV: <presence type='unavailable' to='xxx@localhost/coccinella' >from='[EMAIL PROTECTED]/mats'/> > > Best Wishes, Mats > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev Regards, David -- David Sutton Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
