Hey guys,
I’'m in the process of moving our legacy IM system (simple console messages going through write on unix) to jabber. I firstly went with jabberd2.
We had a system in place where users could create what we called .friends files, containing a list of usernames, and these names would highlight in our modified version of the users program. The users grew quite attached to this file as such I wrote a small perl script to convert .friends files into jabber rosters for jabberd2, and that worked perfectly fine.
Now, I was trialling other jabber servers first I went to ejabberd and then I tried wildfire, now that I have I wont be changing Very impressive.
However this leaves me having to amend my perl script to work with wildfire. The jiveRoster table is simple, all except for the rosterID’'s.
Jabberd2 used an auto incremement feature for id’'s wheres as from looking at the db schema and the source code wildfire uses its own id maintanence system.
I have found the jiveID table but thats where the trail stopped, I’'m having trouble deciphering it.
Basically I cant figure out how to pick the next available rosterID using the jiveID table, and consequently how to modify the jiveID table when I get that far.
Any help in pointing me on the right track with this would be very much appreciated.
Hi skyhawk,
Welcome to the Jive community.
The idType for rosterID is 18, so using SQL you’'d do something like:
SELECT id FROM jiveID WHERE idType = 18;
Of course, you’‘d also want to update the id value in the jiveID table when you’‘re done. An alternate (and probably safer/better) solution would be to use the User Import Export plugin. You can format your existing user data into an xml file which you can then imported directory into Wildfire; details on how to do this are in the plugin’'s readme file.
Hope that helps,
Ryan
Hey
Thanks for that, yeah I spotted the import system alright. Whats stopping me from doing that has been
that the idea was a user could run the script which converted their friends file and then could immediately log into jabber.
Making it easy to convert from the old system to the new.
The new jabber system auths off our ldap system so they can login the same way they do to our console.
The import system would need admin interaction, unless I missed something on that front ?
oooooooh I get it now
You look up the idType of 18 to see what the related id is set at. The id range goes up in blocks of 5.
So you add rosterID’'s up until the value the id is currently set to, then you increment that value by 5 to set
the new block range and repeat.
The only thing I dont know now is how to decide on the next available ID but I presume I can just select the highest current rosterID
from the roster table and start from the next value up.
Whats stopping me from doing that has beenthat the idea was a user could run the script
which converted their friends file and then could immediately log into jabber.
Ah, gotcha. Yeah, since everyone has their own file that would make it a little tough. If you could get those files you could pre-populate Wildfire with all their data so it’'s ready for the users when they first log in.
You look up the idType of 18 to see what the related id is set at. The id range goes up in blocks of 5.
So you add rosterID’'s up until the value the id is currently set to, then you increment that value by 5 to set
the new block range and repeat.
Yes, correct. The blocks of 5 is completely arbitrary number so you can increment by 1 if that makes it easier.
The only thing I dont know now is how to decide on the next available ID but I presume I can just select the highest current rosterID
from the roster table and start from the next value up.
Correct again. Just be sure that when you are doing all this direct manipulation of the database that you’‘re doing it while Wildfire is not running, else because of the way it caches data you run the risk really making a mess of things. (That’‘s the advantage of using the Import plugin, since it uses Wildfire’'s API you can load users while the server is up and running.)
Cheers,
Ryan
I dont suppose theres a way to refresh the cache ?
Even altering code to have it refresh itself every 30 seconds or so ?
I kinda need to figure out a way for people to add in users using the script whille the server is running.
dont ya just hate having to intergrate with legacy behaviour
Hi skyhawk,
I dont suppose theres a way to refresh the cache ?
Sure, although right now it can only be done manually by signing into the Admin Console and navigating to Server → Server Manager → Cache Summary. However, it wouldn’'t be too difficult to write a plugin that you could “ping” in some way to trigger a cache refresh.
Even altering code to have it refresh itself every 30 seconds or so ?
Sure, you can actually do this without changing any code. Take a look at this post but there are two things to note. One, changing any of these values requires restarting Wildfire for the changes to take effect. Two, decreasing the cache size or expiration time (especially to something like 30 seconds) could significantly decrease Wildfires performance and increase the load on your database.
Hope that helps,
Ryan
Thats excellent thanks.
Wow excellent software excellent support, you sure this thing is open source ?