I am developing a Chat for mobile Application Using XMPP protocol , After Successful implementation of one to one chat , now at the stage of multi User chat (MUC) with lots of confusion because there are three different MUC implementation approaches available Traditional MUC, Muclight , MUC Sub , now lots of Question
IS there any approach other than this?
Which approach are best to implement?
What are pros and cons of different approaches?
Which approach is the most advance one?
Which approach is less problematic?
Which is most reliable?
DISCLAIMER: I work for Erlang Solutions which develops MongooseIM, therefore MUC Light.
I'll try address your question point by point:
Is there any approach other than this?
There's MIX, a new (in comparison with traditional MUC) PubSub based group communication/signalling solution for XMPP. I'm not aware of any openly available implementations, but there seems to be some consensus in XSF to make it the official successor to traditional MUC.
From an implementor's perspective, PubSub is probably the longest and most complex of all XEPs (XEPs are XMPP Extension Protocols, or simply speaking additional XMPP features). MIX is built on top of PubSub, which adds yet another layer. I have no hands-on experience with MIX, but guessing from the volume of the relevant specifications, it's not the easiest solution to get started with.
At the same time, PubSub (therefore MIX) is mobile friendly, i.e. the user experience doesn't degrade with frequent connection interruptions, does not rely on presence updates, is easily archivable so that multi-device sync is probably quite easy.
Which approach is the most advanced one? Which approach is less problematic? What are pros and cons of different approaches?
Traditional MUC defines a rich set of roles a user can take in a room (visitor, participant, moderator), privileges (what a user can and can't do) and affiliations (can a user join some room? is he/she the owner? kicked/banned?). It's based on conventional structure of IRC channels, but standardises the concept. The model is quite rich, but at the same time probably a tad too complex. Traditional MUC heavily relies on the client having a constant connection with the server - a disconnection requires the client app to explicitly rejoin any rooms it was in. There's no standard way to tell what rooms a user is a member of, so this information has to be stored in the app/device.
I'm not sure how traditional MUC compares with MIX with regard to the room/subscription model.
Judging by the official documentation, MUC/Sub is an extension to traditional MUC retaining all the original features and adding a PubSub-like option of subscribing to messages, without reliance on presence exchange and constant connection with the server. Other (most? all?) interactions are also possible, while the necessity to exchange presence stanzas is lifted. As far as I know, it's only implemented in ejabberd.
MUC Light (don't miss the developer's guide for some extra details) takes a different approach to enable group communication for mobile devices. It simplifies the traditional MUC role/affiliation model (which might be a good or a bad thing, depending on your requirements), does not require a constant connection with the server and presence exchange to join/leave a room (which definitely is good for mobile devices) and comes with a traditional MUC protocol compatibility layer (although it also introduces a new, simpler, protocol layer). Implementation wise, MUC Light rooms should scale better than traditional MUC rooms in MongooseIM, and due to the their design are more fault-tolerant.
Which approaches are the best to implement?
Let's start with the available implementations:
To sum up, what is "best" to implement depends on your requirements. If you're familiar with PubSub and use it for other cases, MIX might be the way to go (if suitable server wide implementation can be found / developed). Traditional MUC will do the job if you need the rich chat room model and feature set, but making it work on mobile will feel clunky. MUC/Sub might alleviate this feeling, but I don't know about client lib availability. MUC Light is quite simple, but it may be limiting in some rare cases. Still, it's probably the easiest to start working with.