this is nothing fundamentally different than what IRC has been doing very successfully for 17 years. Distributed MUCs rounds out the feature set of XMPP by filling in the last major reason people still use IRC today. but if that's not enough, other use cases for distributed MUCs:
1) server vendor independent muc clustering and redundancy. instead of relying on single vendor you can use several. 2) low bandwidth or disconnected operations. For example, many of the oceanographic research vessels now use IRC for communications and coordination instead of voice communications Why? because IP communications is cheaper and more reliable and they need to keep a satcom IP link up for email and other services, so many of the vessels use IRC since its low b/w and has distributed rooms so users can still be in their chat rooms even when the satcom goes down. When comms come back up the chat servers reconnect and sync up. its largely transparent for the users. As for your question in a previous email about using " good, distributed XMPP server deployment" that doesn't work in coalition and interagency environments where you can't for technical, political, economic reasons control the other parties' server configurations (o/s or server vendor). yes there are lots of people who need distributed muc other than just the military. Research Organizations, Banks, UN Agencies, NGOs/IGOs, etc..... There is a reason people use products like Groove (secure but not scalable) and protocols like IRC (scalable but not secure) with distributed MUCs there will be one less reason to use either of them yet get the advantages of both - security and scalability. boyd -----Original Message----- From: [EMAIL PROTECTED] on behalf of Justin Karneges Sent: Mon 6/11/07 11:07 PM To: XMPP Extension Discussion List Subject: Re: [Standards] distributed MUC rooms On Monday 11 June 2007 10:29 am, Tomasz Sterna wrote: > Dnia 10-06-2007, nie o godzinie 10:07 -0700, Justin Karneges napisal(a): > > I was referring to an internally distributed MUC owned by a single > > entity. > > Nobody would "join" the distributed MUC environment. The owner of the > > MUC could deploy more nodes, but that's all. In this case, a > > proprietary clustering protocol is perfectly acceptable > > So I personally do not see the role of XSF in designing such a > proprietary protocol. Right. If the XSF were to design a protocol, it would be like the one already proposed, and I said that in my first mail. :) > Then, what is the point of detouring the topic on XSF Standards list? We already had "groupchat 0.9", and then MUC. With distributed MUC, we approach yet a third type of protocol, which may cause more pain and changes for implementers to bear. If distributed MUC is intended just for niche or internal military use, fine. But when I see people talk about distributing "jdev".... well, that doesn't sound so niche does it? It sounds like now everyone should have to add support into their clients, for what appears to be nothing more than some sort of IRC cool-factor. According to the spec, it looks like the impact will be very minimal to clients, and in fact is made out of MUC constructs in such a way that all existing MUC clients won't break (the user will just have to manually accept an invite). Maybe this is not so bad, and not much work to implement either. Even still, I'd prefer to see some better justification. The mention of battleships is not convincing. :) -Justin
