[ejabberd] XEP-0045 Implementation

Olivier Goffart ogoffart at kde.org
Sun Nov 26 22:32:08 MSK 2006


Le dimanche 26 novembre 2006 18:34, Mickaël Rémond a écrit :
> Le 26 nov. 06 à 04:44, C00I90WN a écrit :
> > According to the XEP, the MUC should allow multiple joins to the
> > room if the bare jid are the same, is it possible to see a fix for
> > mod_muc to act accordingly with the XEP?
>
> As you said, the spec says "SHOULD". It is not really a "fix" as not
> implementing a service that way do not break compliancy with XEP-0045.
>
> However, I am interesting in knowing more about your use case. Do you
> have example when this feature is useful ?

Hi,

I am one of the person who asked, on standards-jig to have this in the MUC 
specification.
As an user, I see the importance of this when we are connected from different 
computers, and want to be connected from different places  (like when we have 
a irssi in a screen) 


I have tried to modify ejabberd's mod_muc in order to do that[1].  But my 
implementation try to not modify too much data structure and concept, which 
is not possible.  I think that the data structure need to be completely 
modified, which will require almost a rewrite of the mod_muc to do that.

Also, I faced to some design choice :
- it's easy to redirect <presence/> and groupchat messages to each of resource 
present on the room. But what about <iq/> or private messages ?  Do we send 
this to the connected resource with the higher priority ?
- What to do if the user change his nickname for one of his resource ? Do 
every resource change their nickname,  or do we split the user in two ?


[1] I still have the modification locally on my computer
-- 
Olivier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.jabber.ru/pipermail/ejabberd/attachments/20061126/41eb80a5/attachment.pgp


More information about the ejabberd mailing list