[Standards] distributed MUC rooms
stpeter at jabber.org
Mon Jun 4 16:29:31 UTC 2007
Michal 'vorner' Vaner wrote:
> On Fri, Jun 01, 2007 at 09:37:15PM -0600, 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.
> I like it, but few notes:
> • Section 3.4 should say that the "other instances" must send the
> message to its local occupants too and not again to other instances (to
> prevent looping).
> • Can a peerhost connect to other peerhost?
Yes. Or at least I see no reason to forbid that.
> • Who has the last word when the firsthost dyes? (That will be in 3.6,
Yes, that's hard. Maybe I stopped working when I realized I had gotten
to the hard parts. :)
> • I did not notice a way to make my muc component connect to some other
> room. Will it be done by ad-hoc or there will be some special support
> for it?
I don't think I understand your question. Do you mean that your
component would be an occupant in another room?
> By the way, I would know about more usecases. First, MUC aliases (every
> big server could have the same jdev room and you could be sure if you
> join it anywhere, you are home).
Good point. I guess that the list of registered roomnicks is something
else we'd need to share and sync between instances.
Another challenge may be ensuring that room names are unique across
peerhosts (e.g., what if you try to create a room "jdev" and a peerhost
already has a room by that name?). One solution would be to specify that
room JIDs are UUIDs, but I don't know if we need to go that far.
> Second - maybe interconnection between
> some IRC transport and usual MUC?
I don't know if that belongs in this document or in a spec that defines
how to gateway between IRC and MUC.
> And third - large MUCs - every single
> service does less sending, so there is less stress on the line and so.
BTW, about saving traffic in large MUCs, I think also we would want to
suppress presence for the majority of participants. There is a room
config option for this in XEP-0045 ("muc#roomconfig_presencebroadcast").
> Anyway, I really like this one.
So far so good. But it needs more work!
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards