[JDEV] Re: MUC problems

David Sutton jabber at dsutton.legend.uk.com
Wed Feb 12 03:07:01 CST 2003


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 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!
> 
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='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.
> 
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 at service/nick). If
you browse room at 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='girls at conference.localhost' type='unavailable'/>
> > > RECV: <presence type='unavailable' to='xxx at localhost/coccinella' from='girls at conference.localhost/mats'/>
> 
> Best Wishes,   Mats
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev

Regards,

  David
-- 
David Sutton
Email: dsutton at legend.co.uk
Jabber: peregrine at legend.net.uk



More information about the JDev mailing list