[JDEV] Re: MUC problems

Tue Feb 11 11:40:23 CST 2003

> > 1):
> > 
> > In creating a room I get:
> > jlib0 muc create girls at conference.localhost mats callback
> > SEND: <presence id='1007' to='girls at conference.localhost/mats'>
> >       <x xmlns='http://jabber.org/protocol/muc'/></presence>
> > RECV: <message type='groupchat' to='xxx at localhost/coccinella' from='girls at conference.localhost'>
> >               <body>This room supports the MUC protocol.</body></message>
> > <presence id='1007' to='xxx at localhost/coccinella' from='girls at conference.localhost/mats'>
> >       <x xmlns='http://jabber.org/protocol/muc#user'>
> >               <item jid='xxx at 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!

> > 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.

> > 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='girls at conference.localhost'><query xmlns='jabber:iq:browse'/></iq>
> > RECV: <iq type='result' id='1011' to='xxx at localhost/coccinella' from='girls at conference.localhost'>
> >               <conference xmlns='jabber:iq:browse' name='girls' type='public'>
> >                       <ns>http://jabber.org/protocol/muc</ns>
> >                       <user name='mats' jid='girls at conference.localhost/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
> girls at conference.localhost/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.

> > SEND: <presence to='girls at conference.localhost' type='unavailable'/>
> > RECV: <presence type='unavailable' to='xxx at localhost/coccinella' from='girls at conference.localhost/mats'/>

Best Wishes,   Mats