[Standards] distributed MUC rooms
Michal 'vorner' Vaner
vorner at ucw.cz
Tue Jun 12 09:36:39 UTC 2007
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards