[Standards] distributed MUC rooms

[Justin Karneges]

On Monday 11 June 2007 10:29 am, Tomasz Sterna wrote:
> Dnia 10-06-2007, nie o godzinie 10:07 -0700, Justin Karneges napisał(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. :)

-Justin