A good place to hash out ideas is also http://wiki.jabber.org/index.php/Talk:NGMUC
My comment on mirroring mucs: """ I've been thinking about this one recently. You could create a 'muclinker' component that sends presence to all rooms you want to 'mirror'. That will make all the rooms send you the presence and messages. You receive these messages and 'bounce' them to the other rooms. By making this a component you can track enough state in the entities jid that you don't actually need to store much state on the component. All of this requires no code changes to any muc implementations. XEP-0033 support could be added to reduce the bandwidth consuption. If you're going to make code changes and enhance the muc XEP, then I think it would be best to add something to allow an authorised external source to control the network linkages, and fail-over. This way the muc's can concentrate on doing what they're good at, and people can implement their own auto fail-over designs, and swap them out at will. """ On 10/25/06, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
I've been planning to write up an approach to this soon (probably next week), based on discussions I've had with people in the same situation. But more discussion is better! :-) Peter Don McGregor wrote: > I've got an unusual deployment environment that may > require some custom server code, and I'm kicking around > ideas for how to handle it. > > The use case: I've got multiple remote XMPP servers > talking to a relatively well connected and stable XMPP > server hosting MUC. The IP connections between > the remote servers and the muc server are highly > unreliable; I'd expect TCP connections to ungracefully > go down several times per hour, and the downtime > may be from minutes to hours. > > Users authenticate to their local server and > join the MUC on the central server. There > may be many users on the local server; when > the S2S connection goes down I'd like to > have the users on that server to be able to > continue to chat with each other. When the > S2S connection comes back up the local messages > should be sent to the MUC server, and the > MUC server's history since the dropped connection > should be sent to the users at the remote site. > > What I'm thinking is that I can modify the > Wildfire server and place an "interceptor" > piece of code/pattern on the XML router. This > develops a list of local users, and when it > detects a dropped S2S connection it begins to > spool up local messages. It also delivers the > messages to local users. When it detects > that the S2S connection has come back up, > it sends the spooled messages to the MUC, > and requests the history of the MUC since > the connection dropped. > > Good idea? Bad idea? Is there a better way > to handle this situation? >
-- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
