[Standards] distributed MUC rooms
Fletcher, Boyd C. CIV US USJFCOM JFL J9935
Boyd.Fletcher at je.jfcom.mil
Tue Jun 12 03:50:47 UTC 2007
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.
From: standards-bounces at xmpp.org 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. :)
More information about the Standards