[Gossip-dev] Re: [Telepathy] GossipProtocol problems

[Mikael Hallendal]

Robert McQueen wrote:
> Mikael Hallendal wrote:

[...]

> 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:

It's very simple for Google Talk, they control server and client and can
define how it works in their network. A jabber client in the real world
doesn't have that luxury unfortunately.

> 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

We use a similar algorithm in Gossip and it works very well when both
sides are using Gossip but easily breaks when another client comes into
picture.

The thing is, it can be quite annoying to not be able to contact someone
just because he is not using auto-away/get back and is for example
sitting with Away on at all times.

We've tried quite hard to hide the resources in Gossip and it works well
most of the time (all of the times if both ends use Gossip) but as soon
as one end uses Gaim/Adium you can start seeing issues.

Also, the XMPP specification for servers specify that the server must
deliver a message with no set resource to the one with highest priority,
only in a tie can it chose to use recent connect times, availability etc.

>> 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.

I meant, that person A and B wanted to have a session while in the
meeting (to paste a link, to share a whiteboard over their computers
what not). Person B might be equally busy as A in term of those outside
the meeting room.

The fact that Telepathy doesn't support it doesn't mean anyone not using
Telepathy (the majority of the world for now ;) ) to do it since most
Jabber clients support it.

Telepathy is a framework, and imho, shouldn't specify how the UI can be
implemented. But it should be up to the UI layer to deal with these things.

Cheers,
  Mikael Hallendal

-- 
Imendio AB, http://www.imendio.com/