Possibly. In any case we should move this conversation to Standards-JIG. -JD
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Don McGregor > Sent: Wednesday, October 25, 2006 5:17 PM > To: Jabber software development list > Subject: Re: [jdev] MUC Across Unreliable S2S > > > IRC, as I understand it, generates a spanning tree of > the servers involved, and from what I read in the RFCs > people are complaining about that. > > Something NNTP-ish might work, with each site > giving a unique ID to each message and advertising > what messages they have. > > There are also some room management issues if > you go distributed--who has authority to do what? > > > On Oct 25, 2006, at 4:09 PM, JD Conley wrote: > > > 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? > >>> > >
