On Saturday 09 June 2007 8:29 am, Tomasz Sterna wrote: > We should study the IRC protocol carefully and all its variations and > extensions implemented in the most advanced IRC networks out there, > before designing our own distributed chat protocol. > These guys had been battling this problems for ages now
I question the purpose of distributing a single MUC room across many public XMPP servers. You're right, we should probably look to IRC if we want tips on how to do that, but why do we want this at all? I thought the only reason individual IRC rooms were distributed was simply a side-effect of the fact that every IRC server must host every room. All ten thousand rooms of some IRC network are each hosted by every IRC server within that network. With XMPP MUC, a single room is not distributed (not publically, at least), but the global collection of rooms is distributed. This allows for greater security and manageability of the individual rooms, and no network segregation. I've generally considered this approach to be superior to IRC. Peter mentions distributed MUC being useful in a tactical environment. Wouldn't it be enough to just use a good, distributed XMPP server deployment, that also supports distributed MUC internally? Additionally, distribution is a hot topic, and everyone has different internal approaches (including special wire protocols between nodes). Just read any blog about ejabberd. I think it is best to leave this issue up to individual implementations. The proposed XEP would allow for distributed MUC nodes to be external, owned/operated by different people, and potentially running different implementations. Sure, standards are good, and this is exactly the kind of spec we'd promote if it were needed. I'm just not convinced anyone needs it. Who will implement it? It is expected that general IM clients should support it? (this is my concern) I hope that we are not trying to clone IRC's behavior just for the sake of saying we can. -Justin
