Justin Karneges wrote:
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.
Exactly.
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.
From point of view of fault tolerance and failover, a distributed
server/muc is much better imo than distributing the rooms across servers
in domains (and so implementations).
But Peter indicated that failover/scalability/fault tolerance (from this
point of view) was not the only thing he was addressing. He had a nice
description using battleships, etc - forgot it :)
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)
From what I understand, other than redirecting client to another room
(already present ?), they should not see any difference from standard muc.
So clients should not even be aware of whether the room is distributed
or not.
How the rooms across domains keep themselves in sync, in face of
partial/complete failure of communication, how they sync up
config/current room state, etc - that would be quite interesting problem
to solve (apart from the other issues already mentioned here).
Regards,
Mridul
I hope that we are not trying to clone IRC's behavior just for the sake of
saying we can.
-Justin
