powered by Jive Software

Multi domain Openfire *

OK, it’s not really multi domain Openfire but someone in our team had this suggestion for being able to simulate a multi domain environment with one Openfire installation and it’d be good to know people’s feedback. It’s not very XMPP and it’s a bit dirty but our company wants multi domain chat for all the ‘ventures’ we look after and if we can’t achieve this in some way with Openfire we’ll have to look into other options.

Basically what we’re trying to achieve is having john@company1.com, john@company2.com and john@company3.com, all happily chatting away unaware of each other in MUC rooms on the same box.

The idea is:

  • Create multiple MUC services, one per domain (company1, company2 etc)

  • Configure our chat client (we custom wrote one in Flex/XIFF) to only service discover on the domain the user is part of

  • Store the user’s details prefixed or suffixed by some special character, for example _.

The room names wouldn’t need to be unique as the composite key is service ID and room name combined.

Could anyone think of any problems you might encounter if we went down this route? The idea is to NOT change the openfire code as it’ll make it really hard for us to keep up with new releases…

Thanks!

Hi,

why do you want to create multiple conference services?

As far as I understand your requirement a direct chat is not needed and you need only one MUC for every company.

So I would create a chat room for every company using the default conference service.

Anyhow I wonder how you want to managers users of different companies in one Openfire instance. Every day one leaves or retires or a new employee is hired.

LG

Thanks for the response : )

Sorry, I probably wasn’t that clear on the requirements, each company would have a number of MUC rooms each. By using multiple conferences we could have the clients discover the relevant MUC rooms via service discover of a particular conference service. This way rooms could be added and removed without changes to the client code.

The persistence of users is not such an issue - we use an LDAP type service for authorisation so I’m trying to work out what else the ofUser table is needed for. If it wasn’t for roster management I think we could get away with not even storing the users in there.

If you want to implement multiple conference services you should wait for the next release or use the svn trunk. In the 3.6.4 there are a lot of bugs (e.g. OF-32 and OF-33) with multiple domains.

Thanks Guenther,

Yes, I saw these changes and we’ll hopefully be on 3.7.0 if/when we implement this multi-domain solution. It’s cool to see all these multi conference bugs sorted out.

Any ideas when it is going to be non-beta?