10
votes

I am developing a instant message module (part of J2EE web app) using openfire/jsjac within the protocol of XMPP (Jabber).

The openfire users/groups management/tables has been redirected to our business database tables,which means I do not need to maintain users/groups in openfire any more. all the users/group relationship has been set in business database.

Below is the Image i draw about the main pane according to requirement. because of my low reputaion i can not post an image, So i post a url for the image of my instantmessage main UI. Sorry for the unconvenience. instantmessage main UI Image

You guys can see that in the left pane,there are not a users/groups list.There are sessions saved according to history, which puzzle me,specially about group. I read the "XEP-0045: Multi-User Chat" from XMPP.org. I know about general workflow about group chat: XEP-0045: Multi-User Chat"

  1. Create the room,produce the roomJid.
  2. Configure the room.(reserved room)
  3. get usersjid from business database and bind(add)users to the new created room.
  4. send message to the room.
  5. Service will send message to all group members.

And knew about that there is room type is persistent room is explained as "A room that is not destroyed if the last occupant exits; antonym: Temporary Room." by doc. And in the same doc there are some sentences said:

A room owner MUST be able to destroy a room, especially if the room is persistent. The workflow is as follows:

  1. The room owner requests that the room be destroyed, optionally specifying a reason and an alternate venue.
  2. The room removes all users from the room (including appropriate information about the alternate location and the reason for being removed) and destroys the room, even if it was defined as persistent.

After reading the above sentence, i am more puzzled, there are several problems i am still confused.

  1. what is meaning of "occupant exits"? if a occupant log out from the system(offline),is that mean "exist".And all the occupants are offline, is that means the "persistent type" will make the room we created kept existing? So where the room info are saved? in openfire or somewhere other?
  2. Assume that all the occupants exist(offline), althrough this created room was not destoryed, how about the binding information? i mean assume that one user was granted membership by owner(admin), if this user exist or offline, the persistent room will keep his membership role, right? in other words, as long as the room is not destoryed, all the configuration and binding info will not lost,right?
  3. How about the situation that the openfire server encounter restarting, whether the created room and its information are still there?
  4. how to re-find the created room if the owner re-login? through saving the room id?

besides the above question, I thought the workflow to realize the MUC with a persistent room. would you please check that and see what problem existed in the flow?

My workflow for the MUC with persistent room

  1. The owner send presence object to server to creat room and give the room JID, and set the room ID.
  2. The owner send IQ object to Server to configure the created room and set room type as "persistent".
  3. The owner send IQ object to grants other users the membership role.(binding info)
  4. The owner send message Object to ROOM jid, and ROOM jid will forward all the message to its binded members.
  5. Common members of this room handle message(receive) and get the room jid and room id (i hope all users including owner can use this room id to re-find the room when they relogin.. )

So no matter what the role is , owner or common member, how to refind and rejoin the created room according to the room jid or room id with a precondition that the room type is "persistent"??

3

3 Answers

2
votes
  1. The spec says "must be able to destroy", not "has to destroy". Persistent MUCs do not get automatically destroyed when the last user leaves the MUC

  2. I depends on the implementation of the MUC component. If it stores the persistent MUCs on persistent storage, then it's able to reload all persistent MUCs on restart. IIRC the MUC component of Openfire does so.

  3. Make it persistent.

0
votes

You need to update the java code in openfire so that groups will not be delete if user goes offline.You need to update the code against MUC in openfire

0
votes

I suggest you have a look at the new XMPP feature of MUCLight.

This have multiple functionalities not all but most like whatsapp and to what you are expecting.

The persistence is handled in this MUCLight group type.

XMPP over MongooseIM Server : https://mongooseim.readthedocs.io/en/latest/open-extensions/muc_light/

XMPP over Ejabberd Server : https://www.ejabberd.im/aggregator/categories/2