| Author |
Message |
|
| Guest |
 Posted: Sun Nov 26, 2006 3:44 am |
 |
|
|
Guest
|
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?
Quote: 7.1.10 Nickname Conflict
If the room already contains another user with the nickname desired by the user seeking to enter the room (or if the nickname is reserved by another user on the member list), the service MUST deny access to the room and inform the user of the conflict; this is done by returning a presence stanza of type "error" specifying a <conflict/> error condition:
Example 28. Service Denies Access Because of Nick Conflict Code: <presence from='
darkcave@macbeth.shakespeare.lit' to='hag66@shakespeare.lit/pda' type='error'> <error code='409' type='cancel'> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error>
</presence>
However, if the bare JID (<node@domain.tld (node@domain.tld)>) of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it SHOULD route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation to determine how to appropriately handle presence from the user's resources and how to route private messages to all or only one resource (based on presence priority or some other algorithm).
Best Regards,
c00i90wn
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Nov 26, 2006 5:34 pm |
|
|
|
Guest
|
|
| Back to top |
|
| Guest |
| Posted: Sun Nov 26, 2006 6:50 pm |
|
|
|
Guest
|
Indeed, I usually use have two or three resources connected at the same time, and I have set bookmarks for a room I usually enter so that it autojoins everytime I connect, with the current ejabberd implementation I have to join the room with another nick, ask the moderator to kick the other resource and then change my nick back to the one I use, that was previously used by the other resource, or sometimes I usally change back and forth from one computer to the other, and needing to part and join everytime the MUC isn't particullary comfortable.
I know a lot of users would be glad if mod_muc followed that SHOULD and allowed to join a room several times from different full jid. In any case thanks for your interest in this issue.
|
|
|
| Back to top |
|
| Guest |
| Posted: Sun Nov 26, 2006 7:33 pm |
|
|
|
Guest
|
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
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Nov 28, 2006 1:00 am |
|
|
|
Guest
|
On Sun, 26 Nov 2006, Micka=EBl R=E9mond wrote:
> Hello,
>
> Le 26 nov. 06 =E0 04:44, C00I90WN a =E9crit :
>
>> According to the XEP, the MUC should allow multiple joins to the room if=
=20
>> the bare jid are the same, is it possible to see a fix for mod_muc to ac=
t=20
>> accordingly with the XEP?
>
> As you said, the spec says "SHOULD". It is not really a "fix" as not=20
> 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 hav=
e=20
> example when this feature is useful ?
This ability becomes very useful in scenarios where muc room nicknames=20
are locked down. When implementing locked nicknames at work we actually=20
worked around this limitation by allowing for an=20
(optional) nickname+'-'+foo system for locked nicknames, but not needing=20
that can be very nice.
=09-Etan
P.S. I keep intending to clean up and submit my patch for locked=20
nicknames (unless I already have, I forget, I'll check later).
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Nov 28, 2006 10:38 pm |
|
|
|
Guest
|
Hello, how did you lock nicknames ?
I need this too, and I also need to use server-generated nickname instead of
supplied one.
> > Le 26 nov. 06 |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
