Re: Re: [Telepathy] GossipProtocol problems

Mikael Hallendal wrote:
> Ok, that might do the trick but would require us to add some notion of
> active chat session to Gossip I guess. Ie. close a channel and open a
> new one at a later point if some timeout is reached.

At the moment I think Eitan added a cache inside the Telepathy protocol,
to retain channels for a certain period of time. Ideally it would hook
up hints from the UI (closed, etc) because Gabble will use the channel
being closed to send chat state notifications in future.

> Now, we currently don't support that the user decides himself which
> resource to contact and it does have a few bad sides. For example, you
> might know that a person is available on a certain resource even though
> that client would have lower priority. Many jabber clients expose this
> in the UI for that reason.

I think it's better if we avoid doing it in all but the situations which
are totally necessary, and I've not yet had many users or testers
complain at me that Gabble's doing it wrong. Actually at the moment
Gabble is reasonably naive, it gets the presence from the highest
priority resource and uses availability as a tie-breaker, and because of
the linked list of resources this prefers more recently received
presence. This is the resource you will message if you talk to that person.

I actually want to make Gabble implement the same algorithm as Google
Talk, which has no user-visable resources at all, but their servers
support it perfectly. I've never seen the client do something I'd
consider to be wrong, using this algorithm:

1. Never send to a resource with negative priority presence
2. Prefer available (i.e. not <show>away</show> or <show>xa</show>)
over non-available presences
3. Prefer resources with presences set more recently, as specified by JEP 91
4. Prefer resources with status messages
5. If everything is identical, choose the first resource by alphabetical
order

> I can imagine in some other use cases it can be even more important
> (though I have no idea of how these are handled inside of Gabble as it is).
> 
> Say for example, Person A is connected from two different desktops with
> resources 'laptop' and 'desktop'. On 'desktop' he is running a chat
> client, say Gossip ;) and on 'laptop' he is running a whiteboard
> application. Person B is going to start a whiteboard session with Person
> A but 'desktop' has higher priority. What will happen?

Selecting based on priority alone is indeed not sufficient. Gabble at
least has support for selecting by a function of capabilities - if you
want to Jingle call someone, it only considers Jingle callable
resources. It should do something similar to the algorithm above.

> And, given that Person B is sitting in the same room as Person A he
> knows that he should target 'laptop' with his traffic. This is a meeting
> and Person A don't want any chat messages getting here so he won't race
> the priority of 'laptop' to be higher than 'desktop'.
>
> How is this handled by Gabble, and if not, I think it has to be
> considered because it would be a quite common use case.

If the person in the meeting doesn't want messages, why should the
person in the meeting with them be able to override that and annoy them
anyway? If we were using the Google algorithm above, the way to break
this tie would be for the apparently-busy Person A to message the
willing-to-be-distracted Person B first, then Person B would have an
active conversation or more recent activity from them.

But no, we don't have support for this. Is it often-requested? We could
consider a way to have multiple/child handles for a contact which
explicitly gave presence for all of his resources, I guess...

> Cheers,
>   Mikael Hallendal

Regards,
Rob