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
