jiveID idType definitions

Could you guys post the definitions of the idType field of the jiveID table please.

I found type 3 to be users , but I cannot determine the type of Roster entries.

Thanks

Just out of curiosity, what is it that you are trying to do in the database? Are you planning to populate the DB with some data?

These are the most common idTypes that I guess you may be interested in:

USER = 3

GROUP = 4

ROSTER = 18

OFFLINE = 19

Let me know if you need more help on this.

Regards,

– Gato

I am inserting user’'s and their roster directly.

We authenticate our networked devices using some other means. The devices request XMPP credentials to an existing non-XMPP server. the server inserts the credentials in the database, adds the new contact to the “master” user’'s roster and gives it back to the device. The device can now log in.

I guess I could use some other means (using the api in jive messenger…) I might do this later on, for now I am porting from the jabberd2 database schema…

thanks for your answer

If you are making a port from jabberd2 to Jive Messenger, it’'d be great if you want to share your migration scripts with the community.

Let me know if you can/want to share those scripts. We may add them to Messenger’'s website as a contribution.

Regards,

– Gato

Actually there is not much to share.

I did not migrate… Only wrote a few lines of java to write to a JiveMessenger schema instead of the jabberd2 schema…

The source in jabberd2 is available, and the source to Jive will be soon… So nothing of interest here…

If anyone is interested, I could share the sql used…

A nice side project would be to provide migration scripts for a number of the other open source/commercial XMPP servers out there. Some like jabberd2 may not be that difficult, but others like XCP (Jabber Inc.) might be more of a challenge.

Hi,

I’‘m throwing together a simple PHP script (don’'t know java!), to create some default rosters for new users. The Jive Messenger (v 2.0.1) database is hosted on a MySQL server.

I’‘m trying to get a handle on how the jiveID table works. I’‘ve watched the values in both the jiveRoster table and the jiveID table to see what happens when entries are added to the jiveRoster table. New roster entries are indeed given a sequential ID, but the idType ‘‘18’’ in the jiveID table doesn’'t seem to follow.

Say the latest roster item was added with an ID of 20, I would expect the entry for idType ‘‘18’’ in jiveID to be 21 (i.e. the next available ID), but this doesn’'t seem to be happening.

In one case, two new entries where added (via the Psi client), one for each end (i.e. user a adds user b and vice versa). The highest rosterID was 23, yet idType ‘‘18’’ had jumped to 26.

I added in some more contacts, and they started at 24 , as you would expect. Where did that come from as the next ID should have been 26 according to the jiveID table? When the IDs did hit 26, idType ‘‘18’’ in jiveID jumped to 31.

Am I missing something obvious?

Any ideas?

Cheers.

BTW looking forward to the group feature (JM-22), as I won’'t have to fiddle with rosters.

Say the latest roster item was added with an ID of

20, I would expect the entry for idType ‘‘18’’ in

jiveID to be 21 (i.e. the next available ID), but

this doesn’'t seem to be happening.

If I were to use the jiveID table and idType ‘‘18’’ as I expect it to work (i.e. retrieve the next ID and increment, as its purpose is a db independent sequence generator), from my script, would that screw up messenger as it would expect some other value?

Or how about just checking the latest ID in jiveRoster and using the next. When finished, update the jiveID table with the next available ID?

No-one is currently using this server at the moment so there would not be any interference from clients. They are on jabberd 1.4, and I’'m trying to prepare a migration of the 20 existing users and roll out to the rest of the company - hence the initial roster manipulation.

Administration is sooo much easier with Jive Messenger. It would be handy to have a roster manager plugin for the admin console - but I don’‘t know java otherwise I’'d have a bash.

Jason,

To answer your first question – the reason you see the jumps in the IDs is that Jive Messenger checks out a block of IDs at once. This means fewer trips to the database. If you update the ID every time you add a new record, that should work just fine.

Thanks for the feature suggestion on roster management – it would be a great things to have in the admin tool so I’'ll add it to the issue tracker.

Regards,

Matt

Thanks Matt,

I’'d decided that must be what is happening, so I just had a go.

It works to a certain extent, the rosters/groups are added correctly with the jiveID table updated each time, but the client doesn’‘t always pick up the new roster entries (roster updated when client is offline), but that should be a client issue. I’'ll play around some more. Anyway, this will be done before an account is accessed for the first time so probably not an issue.

Roster management, but more importantly JM-21 and JM-22 will make Jive messenger an absolutely perfect internal messaging system replacing a clunky lanman broadcast system that I put together a few years ago. Also means we can bring in Macs and remote offices.

Great stuff, keep up the good work.

Jason.

Just out of interest, clients pickup the changes to the roster after a server restart. Is this due to some sort of caching by the server? I assume so, as any roster amendments made by a client go through the server so it would know about the changes.

Is there any way of forcing the server to reload the roster info? Obviously the proper way would be to talk to the server using the API, but as I’‘m not a java person, I’'m a bit stuck there.

Again, this isn’'t a big problem or anything, but it would be nice to know a way around it.

Cheers,

Jason.

Jason,

It’‘s up to the client to ask for a copy of their roster usually. There isn’'t an elegant way to tell the server to reload the roster from the database – once we add the roster management through the admin console feature, it whould work more elegantly.

Regards,

Matt