[Adium-devl] Meta-contact account selection

[Evan Schoenberg]

On Jul 19, 2008, at 11:54 AM, BJ Homer wrote:

> My question is this: is there a reason why the account  
> prioritization could not simply be a reflection of the ordering in  
> the meta-contact list?  It seems more logical to me that we'd simply  
> try every account in order.  If none of those accounts are online,  
> then return the first account which supports offline messaging, and  
> if none of the accounts support offline messaging, just return the  
> first account.
>
> If I were implementing the code, that's how I'd do it.  Perhaps,  
> though, there's a historical reason for the added complexity.  If  
> so, that's fine.  It's just that the test cases are proving quite  
> complex and slow to write, and I figured that if my suggestion would  
> make it simpler and more user-friendly, I wouldn't bother to write  
> the test cases for the complex code.

The existing implementation is the result of a long series of  
iterating on trying to find the best heuristic... and it is very  
possible that a much better solution is to step back and start over  
from scratch, as you effectively suggest.

Historically, reordering contacts within a metacontact was difficult.   
You had to go to the Get Info window (not an obvious place), and  
sorting often failed to stick or to have the expected results because  
the sort ordering code was ugly.

As of 1.3svn, both of those historical problems are resolved.   
Ordering can be done in the contact list, and the ordering will  
actually stick and not result in 'random order between 2 given  
contacts because they have the same order index' which used to happen  
fairly regularly as there was no conflict resolution.

So, one possibility would be to just use the ordering as specified,  
first finding the highest-up online contact and then using the best  
account for that contact by some heuristic, presumably looking first  
for the highest-ordered account which has the contact on its list.

However, a couple cases need to be addressed:
1. What happens when a lower-ordered contact is more available?
	 e.g. your AIM account is online and away, your MSN account is online  
and available, and your AIM account is ordered first? I think that the  
MSN account should be the default destination in that case.  One  
solution to this would be to first look for the highest-up available  
contact, then the highest-up away contact, then the highest-up idle  
contact, etc.

2. How do we want to interact with invisibility?
	The primary reason the store-the-last-used-account/contact technique  
was implemented was because there was a vocal group yelling about how  
they always preferred to talk to their friend's AIM account, which was  
always set to invisible, rather than their friend's MSN account, which  
was online.  We basically ceded the point and said, "Okay, we'll just  
store which contact you messaged last."
	However, I think that this has been superceded at this point, as I  
don't think we ever prefer an offline contact even if it was messaged  
last.  We may just want to treat invisible people as, well, invisible,  
and not worry about this.  If someone is invisible on one account and  
not on another, they clearly deserve to get messaged on the visible one.

Overall, I think you're right that this code is ripe for being brought  
into the modern era; fortunately, it's already been sequestered into a  
module and from there into a single method, so it should be a  
localized change to fix.

Cheers,
Evan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080719/b0ab1917/attachment.sig>