[Adium-devl] Metacontact Plans for Adium 1.1

Andreas Monitzer soc at monitzer.com
Fri Sep 29 01:25:56 UTC 2006


Hi devls,

Since 1.0 is close to be finished (and none of my concerns ;), I  
spent the last few weeks discussing with other Adium developers about  
the plans for 1.1, since that's the point where my SoC-Code will get  
merged into the main branch.

My code still contains a lot of minor bugs related to the fact that I  
was missing some insight into the Adium core (for example, auto- 
reconnect on wake from sleep or app launch doesn't work). Those are  
all properly documented and should be easy to fix for someone with  
more than 3 months of experience in that huge pile of code.

However, there's one major issue, which I identified very early on in  
the development, but couldn't find any easy fix (even with the help  
of some Adium devs). In XMPP, one account can be online multiple  
times, using the concept of "resources", which is a unique identifier  
for each of those connections. For example, one account could be  
online from two different computers, one using the resource "Home",  
and one using the resource "Work". Everybody sending messages to this  
account can decide where it should arrive (there's a priority  
mechanism similar to Adium's for selecting the right one).
In a way, this is similar to Adium's meta contacts (limited to a  
single service). This causes some issues in Adium, since not all  
contact list entries are meta contacts.
I tried to work around this issue in my branch by creating a new kind  
of metacontact (called "SmackListContact"), which acts just like a  
regular contact on AIM (which everything in Adium seems to be  
designed for) and doesn't have any specific resource. For the meta  
contact popup, I had to do some workarounds (involving removing - 
isKindOfClass:[AIMetaContact class] method calls), because I suddenly  
had three levels of contacts.

My workaround seemed to be a good solution. However, I switched to  
using my branch full time for chatting about two months ago, to do  
some beta testing. I've discovered many issues with this  
incompatibility:
* The AIChat is associated with the AIListContact (which has a  
resource), which means that all code that references the  
SmackListContact will not affect the AIChat (this breaks typing  
notifications for example).
* The underlying AIListContact doesn't duplicate all properties of  
the SmackListContact, which means that it doesn't have the avatar or  
its alias.
* The logs are associated with the AIListContact, which means that  
the resource is included in the log's contact name.
* For some unknown reason, every time I receive a message from an  
XMPP peer which is contained in a meta contact locally, I get the  
meta contact popup, even though the messages all arrive from the same  
resource.
* Receiving a message from a different resource of the same contact  
you're already chatting with creates a new AIChat object (plus view).

It'd probably be possible to fix all those issues in the current  
system, but that probably would mean a lot of hunting for - 
isKindOfClass:-method calls, and some rewrites.
David Smith and Ofri Wolfus talked to me about this issue, and we  
came up with a clean solution.

This solution involves rewriting the AIListContact-related code. We  
proposed a hierarchy, where every physical person gets assigned an  
"AIContact" object. This contact has a GUID, a name, an icon, etc  
(basically everything the contact list displays). It does *not* have  
a status. Additionally, it contains a list of "AIAddress" objects [we  
welcome any suggestions for a better naming scheme ;)]. An AIAddress  
object is associated with a specific screen name on AIM, UIN on ICQ,  
JID w/ resource on XMPP, etc, and contains a status.
Before connecting, there are only AIContacts. When an account plugin  
senses that there are some contacts on the user's contact list, it  
wraps them in an AIAddress subclass and adds each of them to the  
specific AIContact they belong to.

What this basically means when talking in terms of the stuff that's  
already there, *all* contacts are wrapped inside meta contacts, plus  
there might be multiple contacts from a single account per metacontact.

As an example use case, sending a chat message can be done either by  
telling the AIAddress, which can do with that whatever it wants, or  
the  AIContact, which will decide what AIAddress belonging to the  
contact has the highest priority, and forwards the message to it.

I talked to ofri about the possible implications to ChatKit. He  
agreed on rewriting the stuff he already has to use this same  
concept, and that we'll have to specify two @protocols, which both  
AIContact/CKContact and AIAddress/CKAddress (names subject to change)  
have to adhere to. This would mean that moving to ChatKit would be a  
simple drop-in replacement once it's ready for that.

However, the downside of this plan is that it involves many micro- 
changes all around Adium's code, which is a non-trivial task. This  
will probably delay the release of 1.1 for a bit, depending on the  
time all developers can spend on it. I'd like to hear your input on  
that plan!

andy





More information about the devel mailing list