You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Bernd Fondermann <bf...@brainlounge.de> on 2010/12/23 12:37:09 UTC
[Vysper][MUC] Nick conflict: Support rewrite
Hi all,
when someone tries to enter the room with an already existent nick, we
currently return a conflict error.
However, we could gracefully rewrite the nick:
"The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks
are locked down)."
Now, we have basically three options:
+ Support rewrite
+ Support it, and make it configurable
+ Don't support it in this case of simple naming conflicts
I'd prefer the first option and would also support the second, since
this situation arises fairly often when clients go to sleep (laptop lid
closed) - where they don't have a chance of sending
unavailable-presence, but on waking up do not resume the session but do
a proper XMPP reconnect. This results in a new resources id, e.g.
effectively a new client connecting to the room with the same nick while
the old inactive resource still holds the nick and for the server seems
still connected. Now the room join fails because of a nick conflict.
WDYT?
Bernd
Re: [Vysper][MUC] Nick conflict: Support rewrite
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Hey
I have no clue as to what happened on this thread :-)
On Thu, Dec 23, 2010 at 12:37 PM, Bernd Fondermann
<bf...@brainlounge.de> wrote:
> Now, we have basically three options:
> + Support rewrite
> + Support it, and make it configurable
> + Don't support it in this case of simple naming conflicts
I'm all for the first option, I think I went with the easiest option
when I wrote the initial implementation.
/niklas
Re: [Vysper][MUC] Nick conflict: Support rewrite
Posted by Bernd Fondermann <bf...@brainlounge.de>.
On 23.12.10 18:00, Bernd Fondermann wrote:
> On 23.12.10 12:37, Bernd Fondermann wrote:
>> Hi all,
>>
>> when someone tries to enter the room with an already existent nick, we
>> currently return a conflict error.
>> However, we could gracefully rewrite the nick:
>>
>> "The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks
>> are locked down)."
>>
>> Now, we have basically three options:
>> + Support rewrite
>> + Support it, and make it configurable
>> + Don't support it in this case of simple naming conflicts
>>
>> I'd prefer the first option and would also support the second, since
>> this situation arises fairly often when clients go to sleep (laptop lid
>> closed) - where they don't have a chance of sending
>> unavailable-presence, but on waking up do not resume the session but do
>> a proper XMPP reconnect. This results in a new resources id, e.g.
>> effectively a new client connecting to the room with the same nick while
>> the old inactive resource still holds the nick and for the server seems
>> still connected. Now the room join fails because of a nick conflict.
>>
>> WDYT?
>
> Well you know, I fixed the missing XmppIoHandlerAdapter.dispose()
> handling. Does that fix your problem?
>
> BerndWithNonRewrittenNick
Yep, great, thanks!
Should we do rewriting nevertheless - or only store the patch somewhere
for future reference?
Bernd
Re: [Vysper][MUC] Nick conflict: Support rewrite
Posted by Bernd Fondermann <bf...@brainlounge.de>.
On 23.12.10 12:37, Bernd Fondermann wrote:
> Hi all,
>
> when someone tries to enter the room with an already existent nick, we
> currently return a conflict error.
> However, we could gracefully rewrite the nick:
>
> "The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks
> are locked down)."
>
> Now, we have basically three options:
> + Support rewrite
> + Support it, and make it configurable
> + Don't support it in this case of simple naming conflicts
>
> I'd prefer the first option and would also support the second, since
> this situation arises fairly often when clients go to sleep (laptop lid
> closed) - where they don't have a chance of sending
> unavailable-presence, but on waking up do not resume the session but do
> a proper XMPP reconnect. This results in a new resources id, e.g.
> effectively a new client connecting to the room with the same nick while
> the old inactive resource still holds the nick and for the server seems
> still connected. Now the room join fails because of a nick conflict.
>
> WDYT?
Well you know, I fixed the missing XmppIoHandlerAdapter.dispose()
handling. Does that fix your problem?
BerndWithNonRewrittenNick