It seems like this calls for an IRC style "network" approach where MUC domains can join a specific network and share room names.
-JD > > 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? > >
