I’m using the Smack/Smackx libraries I can I register to be notified when chat rooms are removed on the server?
Thanks,
-Dave
I don’t think that the protocol provides support for such notifications, you have to poll the channel list and see if the MUC exists.
What seemed to work for me is to add a PacketListener on that connection, for packet types of Presence, and then filter the Packet events for just those of type == Type.unavailable, then I check to see if that is a room that I manage, if so, I remove it.
This seemed to work well…let me know if there are other possible causes of this event being fired so that I can’t assume the room has been deleted.
Thanks,
-Dave
You do have to join the room prior getting the unavailable presence notifications, correct?
That is likely the case, but I guess I don’t know for sure. In my case yes my users will have previously joined the room else I wouldn’t care that the room was removed.
(I’m just trying to keep the internal state of our app correct as I found that if the room is removed on the server our app didn’t know that and kept it in our room map…so then if the user tried to create it again it would fail because our app thought it already existed.)
-Dave
If the JID is a member of a MUC which gets deleted then you will get the unavailable presence notification. But this precondition was not mentioned in your initial question.
Yeah it seems my initial solution isn’t good. I get that same Presence message when ANY user leaves the room too…so I’m not sure how to know when the room was phisically removed on the server… as opposed to when a user left the room…two very different things. (Perhaps there is a way to distinguish between these messages not sure yet.)
Actually I go back to your comment that you thought I’d have to be a member of the room to get the Presence message…I don’t think that’s true as when the user was not a member of the room my idea worked. However since I get the same message when any user leaves the room…and I am a member of the room…I now can’t send a message to that room because my new logic just removed that room (from our app).
So the key for me is to know when the room was removed on the server. You had said I’d have to poll. Maybe there is a better way but we found that getting chat room lists is an expensive operation (large servers with hundreds of rooms…and sometimes remote) so we cache the results and don’t ask the server for a new list too often else it just slows things down too much. But if you say I have to poll that seems to defeat the purpose of the cache. I suppose I could create a background thread that polls…but sure which there was a way to be notified that a room was removed.
Any ideas?
Are you sure that it’s the same presence message? The ‘from’ attribute should be different, it either comes from the JID of the MUC or from the JID of the user that leaves IIRC. See also http://xmpp.org/extensions/xep-0045.html#destroyroom
I don’t think that people who are not affiliated with a room (i.e. have joined it), should get information about the status of the room (destroyed, etc.). That would basically be an information leak. I guess the point is: There is no way to get notified about a destroyed room when you are not a member of that room.
Maybe have a look XEP-45
Yeah I’m not sure if its the same presence mesage…I think the resource is different. When the server removed the room I get this:
from = dgs@conference.winxp-nti/dave
to = dave@winxp-nti/ChatApp
When a user leaves the room I think the from resource was the person that left.
I read the online docs you provided…it seems there is nothing in the spec where the server MUST notify that a room was destroyed. However I don’t think it would be information leak if it did, because anyone can get that same information by calling MultiUserChat.getHostedRooms(con, service) which is what we do to get the original list…so if I can get all the data why can’t I get notified that…that data changed?
Without notification it seems the only solution is to call MultiUserChat.getHostedRooms(con, service) again and again which seems very inefficent.