[Pidgin] #9874: XMPP priority changes not obeyed for pre-existing conversation windows

[Pidgin]

#9874: XMPP priority changes not obeyed for pre-existing conversation windows
--------------------+-------------------------------------------------------
 Reporter:  rafi    |        Owner:  deryni
     Type:  defect  |       Status:  new   
Milestone:          |    Component:  XMPP  
  Version:  2.5.8   |   Resolution:        
 Keywords:          |  
--------------------+-------------------------------------------------------

Comment(by darkrain42):

 Automatically always picking the most available resource would mean that
 there's no way to have a conversation with a resource that *isn't* the
 highest priority, which is bad because there's always the possibility that
 there are multiple "most available" resources (i.e. multiple clients with
 the same priority).

 Pidgin's current behavior, as I understand it, is this:
   * Initial messages are sent to the bare JID. Messages are sent to a bare
 JID until a response message is received.
   * Once a response is received from a specific resource (this includes
 typing notifications, I believe), further messages are sent to that
 specific resource.
   * If that specific resource goes offline, the next message is sent to
 the bare JID.
   * If we receive a message from a specific resource, further messages go
 to that resource.

 The obvious deficiency in this is that there's no easy way to send a
 message to a specific resource (which is something we know about and want
 to fix, but don't have a good solution for at the moment. My personal goal
 is to manage to get them added to the "Send To" window in the same way
 multiple buddies are selectable in a metacontact). One way to work around
 this to close the conversation tab, ensure you have
 Tools->Preferences->"Close IMs immediately when the tab is closed"
 checked, and enter a full JID in the Buddies->New Instant Message dialog.
 The message will then be directed to that resource initially.

 Routing messages directly to a specific resource is indeed valid behavior,
 and I'm not sure we can always rely on the remote server to route to the
 "right" resource (ignoring the use case where one is conversing with a
 not-highest resource) in the situation where there are two resources with
 the same highest priority, as the server is free to pick the "wrong"
 resource in that case (the XMPP specs leave it up to the implementation to
 decide which resource to route the message to (or all)).

 I do think the situation you describe where another resource becomes more
 available but messages are still routed to the now-less-available resource
 is valid, but I'm unsure how to address it without adversely impacting
 other use-cases.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/9874#comment:2>
Pidgin <http://pidgin.im>
Pidgin