Hello On Mon, Jun 11, 2007 at 08:07:09PM -0700, Justin Karneges wrote: > 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. :)
If I'm right, the invitation and redirection is optional, no? So, if we created the multi-jdev, it would be not because of performance (there are ~20 people anyway), but because of the address alias (well, maybe jdev is not the right idea, but I have my own use for such address alias) and wouldn't do the redirects anyway. Therefore, it would be fully transparent for any muc-aware client (groupchat-able clients could join it the same way any other muc room). So I do not see a problem. And imagine situation you have a meeting where 2e5 people will come. Then the redirect is not such an evil thing in that case anyway. (Well, it may be solved other ways too, I know, but this could help and would probably need less expensive software/hardware). I do not say every room should be distributed, but I think this does no evil and can be useful, so why throw it away? -- All flame and insults will go to /dev/null (if they fit) Michal 'vorner' Vaner
pgpuP9UspeMzl.pgp
Description: PGP signature
