On czw, 2010-09-16 at 09:38 +0100, Will Thompson wrote:
1. Assign the new client a fresh resource;
2. Boot the old connection, granting the resource to the new client;
3. Refuse the new connection.
I don't really think behaviour 3 is very useful.
a. Protects you from rerunning the same
On 21/10/10 15:47, Tomasz Sterna wrote:
On czw, 2010-09-16 at 09:38 +0100, Will Thompson wrote:
1. Assign the new client a fresh resource;
2. Boot the old connection, granting the resource to the new client;
3. Refuse the new connection.
I don't really think behaviour 3 is very useful.
On Thu, Oct 21, 2010 at 4:28 PM, Will Thompson
will.thomp...@collabora.co.uk wrote:
On 21/10/10 15:47, Tomasz Sterna wrote:
On czw, 2010-09-16 at 09:38 +0100, Will Thompson wrote:
1. Assign the new client a fresh resource;
2. Boot the old connection, granting the resource to the new client;
On 21/10/10 16:44, Kevin Smith wrote:
I've heard that suggested before, but after consideration I think the
server is the sensible place to deal with this.
The exchange:
client Can I be bob please?
server No.
client Can I be bert please?
server No.
client Can I be beatrice please?
server
On Thu Oct 21 16:28:04 2010, Will Thompson wrote:
I'd argue that any reasonable client should do the right thing
(that is: not reconnect until explicitly told to) if it's booted
for reason conflict/. :)
Entirely agree.
When you've finished fixing all the clients, let me know and I'll
On Thu, Oct 21, 2010 at 4:28 PM, Will Thompson
will.thomp...@collabora.co.uk wrote:
On 21/10/10 15:47, Tomasz Sterna wrote:
On czw, 2010-09-16 at 09:38 +0100, Will Thompson wrote:
1. Assign the new client a fresh resource;
2. Boot the old connection, granting the resource to the new client;
Hello,
On a side note: Openfire does indeed allow you to configure the server in
such a way that it will not accept an already-bound resource (#3, in various
flavours). This is not the default setting though. By default, it uses
option #2 from Wills list (kick the previous connection). You can
