[ejabberd] MUC / JEP-0045

Sergei Golovan sgolovan at nm.ru
Wed Jan 4 22:06:20 MSK 2006


On Wed, Jan 04, 2006 at 11:45:24AM -0700, Peter Saint-Andre wrote:
> 
> The lock is there to avoid certain race conditions, allowing people to 
> discover the room before it has been properly configured (maybe the 
> owner wants to require a password or make it members-only and doesn't 
> want anyone to enter before setting that up), etc. If clients want 
> instant rooms (no locking), they can request that.

I think that the more reasonable behaviour is to make locked rooms only when
user explicitly lcoks it.

Otherwise user (which don't read JEPs, and I think that users souldn't read
JEPs) will be confused with that lock. Moreover, users don't read server
messages, so after room is created user will be very surprised that nobody
goes to his beautiful room.


> 
> See also the note at the end of Section 9.l.1 of JEP-0045:
> 
> ***
> 
> Note: If the presence stanza sent to a nonexistent room does not include 
> an <x/> element qualified by the 'http://jabber.org/protocol/muc' 
> namespace as shown above, the service SHOULD create a default room 
> without delay (i.e., it MUST assume that the client supports "groupchat 
> 1.0" rather than Multi-User Chat and therefore it MUST NOT lock the room 
> while waiting for the room creator to either accept an instant room or 
> configure a reserved room).
> 
> ***
> 
> Just because you don't happen to like room locking doesn't mean you can 
> ignore the spec. Clients have plenty of options to avoid room locking if 
> they want to.

I think that specs should be written carefully and defaults should be chosen
with least surprise for user in mind.

-- 
Sergei 'TeopeTuK' Golovan


More information about the ejabberd mailing list