Due to the recent palver release, I've been thinking more about how we can do muc clustering.
Why: Well IRC's _ONLY_ existing selling point is that it can do 'clusters' of servers that offer a common set of channels, and contacts. What do we have atm: The closest muc cluster opportunity I can think of is probably ejabberd's muc component. It doesn't support erlang's clustering, but with some work it probably could. This still doesn't leave us with a 'standardised' solution. --- If we wrote something from the ground up, and add the requirement that no existing muc implementations need change - how do we do this: Create a component that you give it a list of muc rooms to 'link' together. The component could join each room individually and mirror all joins/parts/messages to all the other rooms as required. This is more intelligent than an IRC bot, because each user's presence in the rooms can be mirrored, at a bandwidth cost. I think the problem with this is that the amount of traffic the component handles increases with the number of people in the rooms. This can partially be 'fixed' by implementing JEP-0033 in each muc server. Alternatively we can add a stanza on the muc join that tells the server: this jid is a mirroring jid, send a copy of all public chats to it, and private messages for users that it's joined to the room. --- This still doesn't leave us with a fully clustered solution like IRC has. Perhaps not having netsplits is a *good* thing! Thoughts? -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
