powered by Jive Software

MUC join vs. create

Perhaps this is a newbie question, but how does one know ahead of time whether to join or create a MUC? Should I use service discovery on the chat service to find out if the room exists already? Or is there a simpler way?

Doug,

As you figured out, in order to find out if a room already exists you have two options.

  1. Pessimistic option: You assume that the room already exists. In this case you will have to use disco in order to find out if the room already exists.

  2. Optimistic option: You assume that the room does not exist. In this case, you can use the #create method to try to create the room. If the room already exists you will get an XMPPException.

If you use #join and the room does not exist, the server will create the room but you won’‘t know if it’'s an old room or a new one. FYI, everytime you create a new room you will need to configure it. The new room will remain locked (nobody can use it) until you send the configuration form.

Regards,

– Gato

  1. Optimistic option: You assume that the room

does not exist. In this case, you can *use the

#create method* to try to create the room. If the

room already exists you will get an XMPPException.

Thanks, I didn’‘t know about the second option. I’'m not sure I like it, though; there appears to be no way to distinguish that exception from other exceptions that might get thrown. Also, it seems odd that it joins the room and then leaves again (which other participants will see).

If you use #join and the room does not exist, the

server will create the room but you won’'t know if

it’'s an old room or a new one. FYI, everytime you

create a new room you will need to configure it. The

new room will remain locked (nobody can use it) until

you send the configuration form.

Right, this is exactly why I was asking about this. There seems to be no way to determine after calling join() whether the room needs to be unlocked, so we have to figure this out before joining. (And come to think of it, doesn’‘t this present a race condition, where someone else can create a room after you’‘ve determined that the room doesn’‘t exist?) Actually, maybe there is a way to determine whether you created a room or not: if your presence info says you’'re the room owner. This will also be true for rooms that you previously created but then rejoined, but either way I think it should be safe to send an empty configuration form.

Anyway, it would be nice if these details were abstracted into the MultiUserChat class interface somehow. Perhaps something like a boolean exists() method that uses disco, and a boolean isOwned() method that checks the user’'s presence packet (or maybe getAffiliation() would be more general).

By the way, it would be handy if MultiUserChat.getMUCUserExtension() (or something like it) were public instead of private.

This is a little frustrating: after I call join(), I call getParticipantPresence(myRoomJID) (in order to check if the user is the owner), but it returns null. I think I understand why this happens: the presence listener that updates the participant map is in another thread from the collector that waited for the presence packet before returning from join(). I can work around this by adding my own participant listener, but it seems like the right thing to do would be for join() to guarantee that the user’'s presence is in the participant map before it returns. Is this doable?