Manage Users/Groups/Rooms from other DB. What's the best way to do it?

Hi there,

We have been in the educational market for some years now and would like to implement an XMPP Service in order to boost collaboration possibilities. We chose openfire because it seems to be fully featured and mature enough to do the job.

Since our clients are always busy and reluctant to learn new stuff, we wanted to implement our service facebook-style i.e. You do your stuff on the site as usual and the XMPP service adapts to the changes. Trouble is, I’ve read on the forums that manipulating the DB directly causes unintentional side-effects (e.g. user’s not showing up in the roster) so I looked for alternatives. The userservice plugin seems to do the trick for users, however we also need an automated process to manage groups as well as services and rooms.

We have around 10k Users and possibly over 400 Groups. The rooms will be spread out over multiple services (one per client) and there will be lots of rooms (one for each project that can be collaborated on). Since we plan on deploying all our clients on the same server, it is also mandatory to manage room member lists for each room so that there is no cross-client chatter.

I reckon this is a very closed system, however this is totally intended since we want the users (lots of them students from primary school) to be able to collaborate in a school context without having to rely on outside tools (most forbidding the user of them up to a certain age e.g. Facebook - 13 years).

What would be our best bet to achieve this without much hiccup. Can this be done with openfire?

EDIT (clarifications):

The basic idea is that you can see the presence of all users from your groups (in school context: classes) when you come in (presence service) and then chat with each one individually if you like (1-on-1). However, since users can use our product to collaborate on projects (e.g. wiki, reports, etc), we also want to use the groupchat feature.

When people start working on a said project, we want the client to connect to that room and chat with other people who are also working on that project (groupchat). Therefor, the room needs to be protected (we were thinking of members-only + memberlist). As of now, our users have to use .Net Messenger or public chat services if they want to work from home or different rooms, which is not always a good thing considering that most our users are underage pupils. Hence, we wanted to deploy the service as a closed chat service, were the only people you can chat with are from your own work/school environment.

We will deploy our own web-based client. Our only problem atm is how to manage the users, groups, services and rooms on the openfire side. We have a very strict model in mind so we need to be able to add/change/remove stuff around as needed.

Message was edited by: Mike

Hi Mike,

It’s not quite clear to me exactly what you would like to have implemented. From the context as you describe it, I think you’re looking for someone to create one or more plugins that allows you to sync the state of your existing backend to that of Openfire. For user definitions, that sounds plausible, but it’ll be harder to do for multi-user-chatrooms.

Have you ever looked into Bosh (which allows you to “do” XMPP over HTTP)?

Could you perhaps provide a rough definition of the interface that you’d like to have defined?

UPDATE after clarification:

As long as you need “management” functionality only, I think things will be relative easy. Management of XMPP entities in general can be done via a standard XMPP extension, called “ad-hoc commands.” This extension is implemented by Openfire, and a lot of default functionality as provided. This all assumes that your backend talks to Openfire via XMPP (e.g: the backend is logged into the XMPP server using an XMPP client connection. It would use an XMPP administrator user). If you want another setup, you’d need to have implemented a custom interface definition (using web services, for instance. The Openfire plugin architecture allows for that too, but that seems like more work and it would implement a more custom solution that what appears to be needed. If given the choice, I’d personally avoid custom implementations and go with standard stuff, when available. That’s up to you though.

Will your webclient be an XMPP client?

As for groupchats: the standard XMPP group chat protocol (“MUC”) seems to offer all functionality that you need. Openfire supports MUC.



I think I’ll stay with standards afap . Well, that basically means I have to ue BOSH then? Login with an admin-account, then apply the settings as needed.

Bosh will allow you to embed an XMPP client in your webpages, so that will be useful. I’m not sure if you need BOSH for the backend management too though. You could use a standard XMPP client connection instead. There are lots of client libraries available - there will most likely be one that suits your environment.