1 of 1 people found this helpful
One of the good things about XMPP is it's portability. You should be able to use any number of XMPP clients to connect to the Openfire XMPP server. Some good ones, but not limiting too, are: Spark, Pandion, Psi, and Coccinella. I've never used Pidgin myself, so I cant tell you how it works with MUC. I have used all of the above clients to connect and chat with on Openfire and have not had any issues with joining chatrooms.
Thanks for your reply!
Yes I agree with your statement that XMPP is great cause of it's portability. I've found that in most cases it solves the problems I'm having.
I'm quite surprised that Pidgin doesn't support this functionality. Maybe I have my configuration wrong, but Pidgin used to be GAIM which is one of the biggest IM clients out there. If anyone has had any success with using Pidgin and MUC, I'd love to hear how they did it!
I'll try setting up one of these other clients and see how that goes, I've used Psi before but not any of the other clients.
I've just downloaded Pidgin to see how it connects to MUC. From what I can see it seems to work fine. I've got three people chatting in the conference room with myself using Pidgin and the other two using Spark. How are you accessing your conference rooms? i.e. Tools -> Room List
I'm quite surprised that Pidgin doesn't support this functionality. Maybe I have my configuration wrong, but Pidgin used to be GAIM which is one of the biggest IM clients out there.
It might be one of the biggest IM clients, but that does not mean it has the best Jabber support. Pidgin is a multi-protocol client which results in these facts:
* most people using Pidgin use it to access the popular proprietary networks, Jabber is less used because it is less popular
* most Jabber devels use a Jabber-only client because these implement th newest Jabber features
* Some Jabber people don't like multi-protocol clients for strategic reasons (including me): multi-protocol clients should not exist because they create choice on the proprietary networks without helping open standards based networks (that's one of the reasons why transports are much better IMO); choice should only exist on open standards based networks (and in particular Jabber )
* The possibility that multi-protocol clients release a version with broken Jabber support is much higher than a Jabber-only client (because the later will become totally unusable, of course) , though the risk will be still small.
* Multi-protocol clients need a more complex software architecture to support the different protocols, this creates another source of bugs and development inertia (see next bullet).
* Multi-protocol clients are more inert; they will be less eager to add a state-of-the-art feature in Jabber that is not supported by the other protocols (or not by the implementation), especially when this breaks things (consistency, other protocols).
All these factors mean in practice that:
* Multi-protocol clients are more likely to contain (severe) bugs in the Jabber support than Jabber-only clients.
* Multi-protocol clients are need more "developer resources" than Jabber-only clients.
* Jabber-only clients are more flexible, are more likely to support the newest XEP( version)s, and will solve bugs in the Jabber support faster.
* Jabber-only clients are better integrated in the Jabber community; I mean, a Jabber-only client will be tested more frequent by devels of other Jabber software. Even if these people do not contribute code to the projects, they report bugs and issues, but also add support for a feature in this client to their software.