I am trying to use Wildfire as a chat-server for my current project. The thing is, I will need to use an existing buddy-list system (both a buddy-list and a blocked-list really, but the buddy list is most important…).
While it seems quite straight-forward to implement authentication and a user/group-provider and plug them into Wildfire, I cannot find a similar way to handle Rosters. Is there a similar way to handle rosters?
If not, is there a “current practice” for how to change the way in which Wildfire gets the roster for a user? Should I re-implement RosterItemProvider to suit my needs? What implications will that have? Does any other parts of Wildfire read the same tables (I could imagine the case of presence-information as an example?) or will the RosterItemProvider provide all access to the database?
The roster for wildfire can be read-only, so I guess I wouldn’'t need to implement everything that is needed for a full handling system…
Roster management is very specific to XMPP. I don’'t think that we are going to let admins configure roster management so that roster information is read from/saved to another backend store. On the other hand, you can populate rosters by using shared groups. Would that fulfil your needs?
Using a shared group seems very promising to what we want to achieve. I assume that wrinting a custom groupProvider working together with a userProvider and authProvider will let us manage all aspects of users and groups through our backend system. (We don’'t want users to be able to manage their own rosters, for instance…)
One question though: It seems that the Group-class does some lookups in the wildfire database for some properties at least. Does this mean that we must keep some information in the wildfire database for each group?
List of groups and group members can be obtained from different backends. Out of the box you can get them from LDAP or the database. If you want to hook them up to another backend all you need to do is create a new class that implements the GroupProvider interface and register it in conf/wildfire.xml as described in GroupProvider.
However, extra information related to groups is kept in Wildfire’'s database. The reason is that information specific to Wildfire is kept in the system instead of being pulled from another place. Therefore, information such us which groups are shared groups is kept in the database as group properties.
Does that mean that I must manually[/i] define a group as shared?
Can my backend store have several groups with the same name, or will that interfere with the way wildfire handles groups outside of the GroupProvider?
My case is this:
A user is to maintain a (set of) buddy list(s) from a web site. These are to be used both for online chat via the web site, but should also be used as contact lists for our xmpp-based client. We wanted to display these buddies as the user’'s roster by extending wildfire, but my initial investigation implies that there is a lot of code to change (and no easy way to do it) in order to provide a roster from a custom location (other than the wildfire db that is).
So I thought to use the shared-groups functionality, providing each buddy list as a group when a user logs on. (from the call to GroupProvider.getGroups(JID userJid) I guess)
Does this seem like a good idea? Or any other suggestions would be greatly appreciated…
Just wanted to post a follow-up here for future reference.
I have implemented my own subclass of RosterItemProvider in order to override the default behaviour of Wildfire. I needed to do this in order to use our custom buddy-list structure (it is used in other systems as well as by wildfire).
The trick was to extend the default RosterItemProvider, overriding the method to load the roster of a user - getItems(String). I also provided overrides to create-, update- and deleteItem, as this is prohibited in our backend structure. Updates to a roster is only to be managed through our normal web-site. Now my custom implementation connects through a ejb-remote interface to our backend-system, and everything seems to be working quite fine