Combine contacts with multiple resources

[sander]

Currently, contacts logged in with multiple resources (multiple clients) are showed as separate entries in the roster. It would be better to combine them.

Current situation:

- Online
  | - Group 1
  | | Contact 1 (resource 1)
  | | Contact 1 (resource 2)
  | | Contact 2

Better would be:

1) collapsed (default)
- Online
  | - Group 1
  | | + Contact 1
  | | Contact 2

2) expanded
- Online
  | - Group 1
  | | - Contact 1
  | | | resource 1
  | | | resource 2
  | | Contact 2

Notes:
* Any action to the collapsed item will be executed on the bare JID (the server will then either send it to the client with the highest resource, or to both clients when they have both the same priority)
* Any action to one of the resources under the expanded item, will be executed on that specific resource (so not the bare JID)
* There should be an option in the menu under Show called "Show resources". When this option is disabled, the user will not be able to expand contact who are connected with multiple resources.
* The option "Show resources" should be disabled by default as only power users need this and most other people would be confused by this.

[Mats (matsben)]

Handling multiple resources wasn't working at all and never has! I have now started adding an alternative to this suggestion. It ios configurable:

    # How to display multiple available resources.
    # highest-prio : only the one with highest priority
    # all : all
    set ::config(roster,multi-resources) "highest-prio"

Normally only the highest prio one is displayed. Instead of having an extra branch in the roster, which doesn't fit the roster plugin programming model at all and would be very messy to do, only the highest prio is shown, but where the branch is instead made on the popup menu. So if you click on a multi resource item you'll get each resource in a sub menu for the "Chat" entry. These can be ordered and the highest prio marked (Default) or something. There is some template code that isn't working yet. First I need to remove the implicit assumption when starting a chat thread (except to room) to use the bare JID as indicated in the XMPP. This assumption must be implemented higher up in the call hierarchy.

[Mats (matsben)]

Chatting now works for multiple online resources. The popup menu entry is split up in:

    Chat... -> JID2 (Default)
               separator
               JID2/res1
               JID2/res2
               ....

I think this is a better solution than pollute the roster tree. It remains to be implemented also for "Message", "Whiteboard", and "Send File" , but I'd like to see how this work out first.

[sander (s-devrieze)]

ok seems ok. But did you also thought about the following situations?:
1) A contact is connected with 2 or more clients with at least 2 resources sharing the same highest priority
2) A contact is connected with 2 or more clients but the resource with the highest priority does not support a specific feature (e.g. when the user wants to send a file, initiate a whiteboard session, start a voice chat session,...)
3) What when the highest priority resource is in DnD presence state whilst a lower is in Free to Chat? Ok, this may not occur as clients should automatically change priority when presence is changed (see another feature wish of mine)...but what if it happens anyway?

Possible solutions:
1) Ask the user to send the message/file transfer request/whatever either to all these resources, or let the user manually select:
* Both (recommended)
o resource1
o resource2
2) Warn the user that the action cannot be done with the current highest priority resource and ask the user to select between the resources that support the required feature (or cancel the action)
3) Show the 'best' presence state in the roster. If this is not the highest resource; show a dialog with all resources and their corresponding presence state (ordered by priority) and allow the user to select between them. Maybe this is a shit solution?

PS: for which Coccinella release milestone will this feature be?

[Mats (matsben)]

On 12/27/07, sander <email address hidden> wrote:
> ok seems ok. But did you also thought about the following situations?:
> 1) A contact is connected with 2 or more clients with at least 2 resources
> sharing the same highest priority

Right now it is indifferent (random) which is displayed. Could go for
presence, then alphbetically on resource.

> 2) A contact is connected with 2 or more clients but the resource with the
> highest priority does not support a specific feature (e.g. when the user
> wants to send a file, initiate a whiteboard session, start a voice chat
> session,...)

So far only the Chat... menu entry done. The rest will be slightly
more complex but
not that much.

> 3) What when the highest priority resource is in DnD presence state whilst a
> lower is in Free to Chat? Ok, this may not occur as clients should
> automatically change priority when presence is changed (see another feature
> wish of mine)...but what if it happens anyway?
>

I only go for priority. It is up to each client to sync priority with show.

> Possible solutions:
> 1) Ask the user to send the message/file transfer request/whatever either to
> all these resources, or let the user manually select:
> * Both (recommended)
> o resource1
> o resource2
> 2) Warn the user that the action cannot be done with the current highest
> priority resource and ask the user to select between the resources that
> support the required feature (or cancel the action)
> 3) Show the 'best' presence state in the roster. If this is not the highest
> resource; show a dialog with all resources and their corresponding presence
> state (ordered by priority) and allow the user to select between them. Maybe
> this is a shit solution?
>
>
> PS: for which Coccinella release milestone will this feature be?
>

Since it is already there, at least the Chat menu...
The rest menus I don't know. Lets test Chat first.
Note that the Whiteboard menu activation is always tested with the
displayed resource.
"Send File" I test after selecting the menu entry for that resource.

[sander (s-devrieze)]

> > PS: for which Coccinella release milestone will this feature be?
>
> Since it is already there, at least the Chat menu...

0.96.4.1 or 0.96.6?

[Mats (matsben)]

Say 0.96.6 since the implementation isn't complete. I'd like to get
out 0.96.4.1 the first days next year.

On 12/28/07, sander <email address hidden> wrote:
> > > PS: for which Coccinella release milestone will this feature be?
> >
> > Since it is already there, at least the Chat menu...
>
> 0.96.4.1 or 0.96.6?
>
> --
> Combine contacts with multiple resources
> https://bugs.launchpad.net/bugs/145330
> You received this bug notification because you are a bug assignee.
>

[Mats (matsben)]

If more than one resource share the highest priority any show element is considered.

[sander (s-devrieze)]

bug found:
1) Contact is chatting using Psi
2) Contact closes Psi and starts Gajim
3) I close the chat dialog with this contact and open a new one
4) When I try to send a file to this contact, Coccinella still tries to send to the Psi resource which is offline. (I use the Send File button in the chat dialog)

[Mats (matsben)]

This last remark is unrelated to the multiple resource code of the roster. It has to do with the Chat dialog alone, and how to treat bare vs. full JID according to http://www.xmpp.org/rfcs/rfc3921.html#messaging sect. 4.1

I can reproduce the bug if I *don't* close the chat dialog when the contact "changes resource". Indeed, the cahed jid3 is the wrong one, but I can't do as the XMPP says and resend to the bare JID because I nned to know the contacts capabilities for file transfer, why I need the full JID. I now instead do:

# Chat::GetFullJID --
#
# Use this for file transfers, for instance, where we MUST have the
# full JID for disco.

proc ::Chat::GetFullJID {chattoken} {
    variable $chattoken
    upvar 0 $chattoken chatstate

    set jid3 $chatstate(jid3)
    if {$chatstate(isroom)} {
 return $jid3
    } else {
 if {[::Jabber::Jlib roster isavailable $jid3]} {
     return $jid3
 } else {
     set jid $chatstate(jid)
     if {[jlib::isbarejid $jid]} {
  set res [::Jabber::Jlib roster gethighestresource $jid]
  set jid3 $jid/$res
     } else {
  set jid3 $jid
     }
     return $jid3
 }
    }
}

[Mats (matsben)]

Slight rewrite:

proc ::Chat::GetFullJID {chattoken} {
    variable $chattoken
    upvar 0 $chattoken chatstate

    set jid3 $chatstate(jid3)
    if {$chatstate(isroom)} {
 return $jid3
    } else {
 if {[::Jabber::Jlib roster isavailable $jid3]} {
     return $jid3
 } else {
     set jid2 $chatstate(jid2)
     set res [::Jabber::Jlib roster gethighestresource $jid2]
     return $jid2/$res
 }
    }
}

[sander (s-devrieze)]

Isn't it possible to update the chat dialog when the contact changes
his priorities? Then the user don't needs to close the dialog each
time and it will work more reliable.

[Mats (matsben)]

But the RFC says:
"
An instant messaging client SHOULD specify an intended recipient for a
message by providing the JID of an entity other than the sender in the
'to' attribute of the <message/> stanza. If the message is being sent
in reply to a message previously received from an address of the form
<user@domain/resource> (e.g., within the context of a chat session),
the value of the 'to' address SHOULD be of the form
<user@domain/resource> rather than of the form <user@domain> unless
the sender has knowledge (via presence) that the intended recipient's
resource is no longer available. If the message is being sent outside
the context of any existing chat session or received message, the
value of the 'to' address SHOULD be of the form <user@domain> rather
than of the form <user@domain/resource>.
"

It says we SHOULD stick to the full JID whenever it is available.
Handling resource issues is very tricky. SOmetimes I wish they used
plain bare JID all the time, but now when the design is like this we
have to live with it. I'm sure there are advantages but...

[sander (s-devrieze)]

> It says we SHOULD stick to the full JID whenever it is available.
> Handling resource issues is very tricky. SOmetimes I wish they used
> plain bare JID all the time, but now when the design is like this we
> have to live with it. I'm sure there are advantages but...

So, send *always* to the bare JID and let the server decide to which
resource it should route the message. All things that need P2P (like
file transfer) need to be updated in realtime.

So:
* chat dialog: bare JID
* Send File function: highest resource; updated in realtime
* Jingle: highest resource, updated in realtime

[Mats (matsben)]

If I initiate the chat I send to bare JID (unless room member which we
disregard ftm)
When I get the first message I keep the full JID and use this each time.
If I get another full JID message I use this JID instead.
When I send file I use the full JID I have obtained the last message
from if still online.
If not online anymore I send to the highest resource.
If no online resource can't send file.

At least this is how it is supposed to work. So it is possible to keep
a chat thread with a given full JID even the contact is online with
another resource independent of its prio.

[sander (s-devrieze)]

What's the status of this bug report? Is this still in progress?

[Mats (matsben)]

I've lost track of it.

[sander (s-devrieze)]

Will it be in 0.96.6 or not?

[sander (s-devrieze)]

not closed as the status of this bug entry is unclear