Wayne, Thanks for the feedback, comments below. On Mon, Jan 9, 2012 at 11:07 PM, Matthew Miller <linuxw...@outer-planes.net> wrote: > On Jan 9, 2012, at 09:06, Wayne Franklin wrote: >> The biggest problem with XEP-0289 is that it does not seem to address the >> requirement for having the room be able to live on if the S2S link is >> disconnected. Our customer would like a 100 user chat room with 50 users on >> one login server and 50 users on another login server to be able to continue >> on as two 50 person chat rooms if the S2S link goes down (which is common >> for their network).
You're not the first people to say this, so I accept I was unclear in FMUC (or flat-out failed to say what I intended). There are two modes defined in the FMUC XEP - master/slave and fire-and-forget. The intention here is that the first mode requires confirmation from the master room for all joins, messages sent etc - this has a number of advantages such as: *consistent views of the room across all occupants (messages arrive in the same order for everyone, etc.) *centralised access control It, as you note, doesn't work if the nodes can't reach each other and doesn't allow 'disconnected' working (and also requires roundtrips, which are jolly expensive on very slow or half-duplex links). The second mode has the opposite properties, and allows disconnected use because it essentially runs a full MUC locally, and then just passes on the stanzas to the other MUC for it to deal with. I think this, if explained better, satisfies your customer's requirements. I'll do a significant reworking of the text to make sure it reflects this, and is clear about it. >> Additionally, it seems as if the user needs to know that they want to >> connect to a new mirror service rather than the actual chat room. This >> seems as if it will be a training issue for our users. >> >> Unless I mis-understand, it seems as if the client will need to know that it >> is talking to this new mirror service (and not a real MUC room) so that it >> can construct this escaped JID. Personally, I would rather make a change at >> the server that did not require the client to create a new kind of JID. The JID translation is really just a convenience (or inconvenience) - it doesn't affect the underlying protocol so I'll remove it from the main text and relegate it to a footnote somewhere. >> As I said, we will respect the decision of the council and provide feedback >> to XEP-0289, but if we can't satisfy the requirement for continued operation >> while S2S is down, we may have to go our own way. > > XEP-0289 is still EXPERIMENTAL, and so could (in theory) be influenced by > such criteria. I would strongly recommend you work with the author(s) of > XEP-0289 to see if an agreement or compromise can be reached. I think it should have already addressed the requirements, as I understand them, but I did a poor job of the first version of the spec. I'll update it in light of feedback and implementation experience, and see if we can get some text everyone agrees on with the next version. /K
