[ejabberd] MUC / JEP-0045

Le Boulanger Yann asterix at lagaule.org
Thu Jan 5 14:30:48 MSK 2006


Badlop wrote:
> 2006/1/4, Peter Saint-Andre <stpeter at jabber.org>:
> 
>>Just because you don't happen to like room locking doesn't mean you can
>>ignore the spec.
> 
> 
> 'Obviously, Doctor, you've never been a 13-year-old girl.' [1]
> 
> If he considers he has good reasons backing his decision, he *can*
> ignore the protocol, right?. Of course that prevents mod_muc from
> being full JEP45 compliant :S
> 

I think it's a problem if each server implements its own version of the 
protocol :/. I don't say JEP is good, I just say ejabberd is not 
compliant with it.

> 
> 2006/1/4, Peter Saint-Andre <stpeter at jabber.org>:
> 
>>If clients want instant rooms (no locking), they can request that.
> 
> ...
> 
>>Clients have plenty of options to avoid room locking if they want to.
> 
> ...
> 
>>A smart client developer will hide complexity from the user.
> 
> 
> 2006/1/5, Le Boulanger Yann <asterix at lagaule.org>:
> 
>>A good client will show the configuration window as soon as he creates the room.
> 
> 
> So, as you already say, if mod_muc implements lock-until-configured,
> several changes are required in all Jabber clients.  We already know
> the opinion of a Tkabber developer (Sergei). Are you interested in the
> opinion of Psi, Gajim, Pandion and Google Talk developers? I can make
> a poll on Tkabber website right now.
> 
> Until the most used Jabber clients are able to deal with
> lock-until-configured, ejabberd admins must have the option to disable
> that 'feature' (even if you get ill considering the possibility of a
> protocol violation).
> 
> Getting real facts, when do you think Psi (the most used Jabber
> client) will be able to deal with lock-until-configured? 2006, 2007,
> 2008?
> http://psi-im.org/development
> 
> I want ejabberd to be fully protocol compliant, but a software product
> must satisfy his users, not a technical comitee. The same day
> ejabberd's SVN gets lock-until-configured support, I'll write a patch
> that adds a new configurable option to revert that behaviour:
> {lock-until-configured, false}. I'll request my patch to be included
> in ejabberd until most Jabber clients are capable of dealing with
> locked rooms themselves. Once they do, I'll ask my patch to be
> completely removed from ejabberd.
> 
> This way ejabberd will be both protocol-compliant and user-friendly,
> both now and on the future, am I right?
> 


Jabberd1.4 (I don't know for 2) has that implemented. There is nothing 
that MUST be done in the client side if developers don't want to do 
something. Jabberd1.4 only sends a message that looks like "Users won't 
be able to join the room until you configure it". So no need to auto 
open the configuration window. It's just nicer to auto popup it. So psi 
and all other clients that support MUC won't have any problem with this 
implementation of the JEP.


More information about the ejabberd mailing list