powered by Jive Software

Manipulating Openfire Database via External Program

I am looking to have a third party program “manage” my Openfire database. That is, I am looking to have another program wrap around Openfire and take control of certain aspects (i.e. roster, group and user account information). How this would work is the program would take in requests / commands (new user creation, new roster items, new group affiliations, and some others) from the users and handle the requests in its own space, and then update Openfire’s database to reflect the user requests.

I thought of two different possible methods of achieving this, and I was wondering if anyone could give insight into which is better (or actually possible). And if neigther are posible, please let me know what would likely be the best way to achieve my goal. And if I have failed to fully explain anything, please let me know of that as well.

  1. The first method would be to create an XMPP client within the program wrapping Openfire that would have the credentials of the Openfire Admin. This client would work in conjunction with the rest of the code, and whenever Openfire information needed to be updated, the client would send an iq set stanza to Openfire to change the user’s information accordingly (update the user’s roster / group affiliation(s), etc).
  2. The second method is to have the wrapping program directly modify Openfire’s database according to Openfire’s database schema. I have already started looking into this method, and have noticed that if I directly modify table informatoin, it does not take effect in the admin console until the Openfire server is restarted. I was not able to test if the changes actually took effect, and it was just that the admin console was not updating. With this method, I know that I would need to properly map the information between the program wrapping Openfire and Openfire’s database, and I have already begun looking at the exact sort of information Openfire needs for the tables I am looking to manipulate.

Do either of these plausible? Or do I need to figure out another way of achieving this goal?

Thanks for the help and advice,

Kyle M. Cummings

P.S. In case anyone was wondering, I need to do all of this to incorporate a bigger social sphere than just Openfire that is accessable from multiple client types (i.e. Android, browser, iPhone…).

I would say you want to write a plugin to accomplish this. This would allow you to make changes to the DB through Openfires API, and thus Openfire would be “aware” of the changes that you have made. Plus they are guarenteed to be done correctly.

You do not want to do number 2, it would be by far the most error prone.

It would be easier to have an LDAP and manage your users and groups directly from there. Especially if you say that you want to use it for something else too.