Hi there. I’'ve been trying to familiarize myself with smack over the past couple of weeks and have run into a wall with this problem. I would like my bot to sit in a MUC room (most likely a bunch of them) and listen for when users join the room so that it can then whisper (room/nick) to them an On Join message like a MOTD or Rules or whatever.
As far as I can tell from reading the JEP-45 and looking at raw XMPP, when a user joins a room, the room broadcasts a presence update for that user to everyone in the channel. However, this presence update does not contain a status or any of the regular “type” fields that the Smack Presence class gives access to. Instead, it simply contains a reference to the MUC website and lists the user’'s JID and their “role=participant” message.
I’‘ve tried using the roster, but not all users are guaranteed to be in my bot’‘s roster. I’'ve also tried using the ParticipantStatusListener checking for every possible role transition (ie visitor->participant, etc), and none of them seem to get called due to the presence message.
Also, I’‘m unclear as to the purpose of the MUCInitialPresence class, which at first glance would seem to be what I want, but I can’'t figure out how it is supposed to be used.
Thanks!
By the way, my server is sending out JEP-45 compliant presence messages, with a slight difference:
<presence to=’‘foo@foobar.com/blah’’ from=’‘room@conference.foobar.com/bar’’><x xmlns=’‘http://jabber.org/protocol/muc#user’’><item jid=’‘baz@foobar.com/cow’’ affiliation=’‘none’’ role=’‘participant’’/>
Hey Jon,
Sorry for the late reply. Today I added to ParticipantStatusListener two new messages. #joined(String participant) and #left(String participant). These messages will be sent when an occupant joins of leaves the room.
You can try out with tomorrow’'s nightly build. Let me know if that helped.
Regards,
– Gato
Hola Gato,
What’‘s the smallest set of changes necessary in order to get this particular update? I’‘m just adding chat support to my application and I think I’'ll be needing this to update the list of users in the room.
Hola Javier,
Just out of curiosity, why is it that you need the set of changes? In general, we recommend using the latest version since it may include many bug fixes.
These are the core modified classes:
smack/source/org/jivesoftware/smackx/muc/ParticipantStatusListener.java 1.4
smack/source/org/jivesoftware/smackx/muc/DefaultParticipantStatusListener.java 1.3
smack/source/org/jivesoftware/smackx/muc/MultiUserChat.java 1.7
And this class includes a new test case for the new functionality:
smack/test/org/jivesoftware/smackx/muc/MultiUserChatTest.java 1.9
Regards,
– Gato
Gracias.
I ended up implementing my own simple presence listener as I only need available and unavailable notifications.
I’‘m using the latest released version. I’'m usually wary of CVS snapshots. Do you still recommend I use them?
I ended up implementing my own simple presence
listener as I only need available and unavailable
notifications.
You can always create an anonymous subclass of DefaultParticipantStatusListener and redefine only #joined(String) and #left(String). IMO, that’'d be the simplest way to go.
I’‘m using the latest released version. I’'m usually
wary of CVS snapshots. Do you still recommend I use
them?
Sure. At the moment we are not doing any refactoring work or big changes to the code so code in the repository is stable.
Regards,
– Gato
I ended up implementing my own simple presence
listener as I only need available and unavailable
notifications.
You can always create an anonymous subclass of
DefaultParticipantStatusListener and redefine only
#joined(String) and #left(String). IMO, that’'d be the
simplest way to go.
Now that you added those methods to the interface I’'ll do that as soon as I pull the changes from CVS. I just needed something to start testing in general.
I’‘m using the latest released version. I’'m usually
wary of CVS snapshots. Do you still recommend I
use
them?
Sure. At the moment we are not doing any refactoring
work or big changes to the code so code in the
repository is stable.
Ok, I’'ll have this in mind, thanks.
Thanks Gato! I tested it and it seems to work. I appreciate the speedy addition, im sure it will simplify things for a lot of bot and client authors.
BTW, for reference, I had eventually figured out that I could do a general ParticipantListener (rather than status) for the channel, but of course, that includes lots of other messages which do not pertain to on-join and on-part, so it required a little bit of tracking to make sure it was a relevant message. No longer needed because of this addition!
I pulled the changes from CVS. I found out that UserStatusListener doesn’'t define joined and left. I implemented that taking advantage of the sequential nature of Smack.
On the other hand, I found out that the ParticipantStatusListener calls the method left for my own user, but the method joined is not called when my user joins the room. Is that the expected behavior? Note that joined is being called for other users.
Another related question: Is participant here what the MUC JEP calls ‘‘participant,’’ or does it mean “occupant but not the local user”?