[Standards] distributed MUC rooms

[Michal 'vorner' Vaner]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20070612/2420badf/attachment.pgp