[Standards] distributed MUC rooms
mridul at sun.com
Sun Jun 3 00:10:27 UTC 2007
Michal 'vorner' Vaner wrote:
> On Sat, Jun 02, 2007 at 06:34:53PM +0530, Mridul Muralidharan wrote:
>> Peter Saint-Andre wrote:
>>> Last October I talked with some folks in the XMPP community about the idea
>>> of distributing MUC rooms across domains. Late this afternoon and this
>>> evening I finally got around to writing up an approach to this problem. The
>>> document I've started working on is quite tentative, but I figured I'd send
>>> it out for feedback anyway (release early, release often!).
>>> I'll try to work on it more this weekend, since I'd like to present some of
>>> the ideas at a conference I'm attending next week.
>> A few thoughts in general.
>> 1) What is the scope of the distribution - is it going to be an muc service
>> spread across domains ? Or is it going to be a single logical muc service
>> (hosted on multiple machines/nodes) ? (With reference to 1.3.3)
>> From examples 5 onwards, it looks like the former case ... might get a bit
>> tricky. Why would a user join muc.example.net for a conference on
>> chat.example.com ?
>> Wont this not be a potential routing issue ?
>> I assumed we will be using something like dix for this - where bare jid
>> is the same, just that it is distributed and fault tolerant. (or integrated
>> into the cluster/pool'ed server).
>> This could also become potentially confusing for clients - where user of a
>> conference is receiving messages from multiple room jids.
> As I got the idea, you never get messages from anyone except the muc you
> connected to. Every MUC would get all messages and route them to its
> local users.
> As I got it, it means different rooms where messages teleport from one
> to every other, so their occupant list and messages are the same.
In which case, how would directed message, iq, etc work ? multiple hops
through the components ? Or are full jids to be shared across
components/rooms in different domains ? (trust conf in remote domain ?
privacy leaks ?)
So we are back to the question of - what is the intention : only high
availability of conferences ?
Or is the intention also to spread them across domains ? So, they end up
talking over s2s (overhead would be quite high in the latter case).
I guess without more clarity on the requirements and intentions, it
might be premature for me to comment more.
I guess my earlier queries stemmed from my not having enough clarity on
More information about the Standards